Guide de configuration de la surveillance de base de données

Avant de commencer

Les vérifications Base de données ne s'exécutent pas depuis le réseau public distribué de surveillance de HostTracker comme le fait une vérification Http ou Ping, donc ce formulaire n'a aucune section Emplacements de surveillance. Au lieu de cela, chaque vérification compose votre serveur depuis l'infrastructure de vérification privée propre de HostTracker, en utilisant deux adresses source fixes : 4.207.101.172 et 20.107.152.200 (Europe du Nord). Avant d'enregistrer le moniteur, ajoutez les deux adresses à la liste d'autorisation du pare-feu ou du groupe de sécurité de votre serveur de base de données, et assurez-vous que le serveur accepte les connexions sur son port depuis l'internet public, ou au moins depuis ces deux adresses. Si le port n'est pas joignable, chaque vérification échoue avec une erreur de connexion, quelle que soit la configuration du reste du moniteur.

Configurez le compte de surveillance lui-même avant de commencer : créez un utilisateur de base de données dédié à la vérification, accordez-lui uniquement ce dont la vérification a besoin (généralement juste la capacité de se connecter, plus SELECT sur la table que touche votre requête), et évitez de réutiliser un compte applicatif ou administrateur. Si la requête que vous prévoyez d'exécuter modifie des données, donnez à ce compte un accès en écriture uniquement à la table spécifique concernée, rien de plus large.

Base de données cible

Trois champs identifient ce à quoi la vérification se connecte, et se trouvent au-dessus des sections repliables puisqu'ils sont obligatoires :

• Type de serveur - une liste déroulante des fournisseurs pris en charge : Microsoft SQL Server, Oracle, MySQL, PostgreSQL, et Firebird.
• Serveur : Port - le nom d'hôte ou l'IP du serveur de base de données, et son port. Changer le type de serveur remplit automatiquement le port par défaut conventionnel de ce fournisseur (1433 pour SQL Server, 1521 pour Oracle, 3306 pour MySQL, 5432 pour PostgreSQL, 3050 pour Firebird) - vous n'avez besoin de le remplacer que si votre serveur écoute ailleurs.
• Base de données (ou, pour Oracle, Service et Nom d'instance (SID) à la place) - le nom de la base de données à laquelle se connecter. Pour Oracle, vous pouvez fournir le nom du service, le SID, ou les deux, selon la configuration de votre listener.

En dessous, un champ facultatif Nom vous permet d'étiqueter le moniteur pour les alertes, les rapports et les widgets - utile dès que vous avez plusieurs vérifications de base de données et que vous devez les distinguer d'un coup d'œil.

Paramètres principaux

Ce groupe contient l'horaire et les deux commutateurs à usage général partagés par tous les types de vérification :

• Intervalle - la fréquence d'exécution de la vérification, proposée de 10 minutes jusqu'à 24 heures (10, 15, 30, 45 minutes, puis 1, 2, 4, 6, 12 et 24 heures), plus une alternative en horaire cron pour un rythme moins régulier. Les vérifications Base de données ne proposent pas les intervalles inférieurs à 10 minutes que d'autres types de vérification proposent.
• Étiquettes - des libellés en texte libre pour regrouper et filtrer les moniteurs ailleurs dans le tableau de bord.
• Journal complet - enregistre chaque résultat de vérification individuel au lieu de seulement des résumés regroupés, utile quand vous avez besoin de voir les temps de réponse ou les valeurs exacts dans le temps plutôt que juste l'historique en ligne/hors ligne.
• Statistiques ouvertes - rend la page de statistiques et de journal de ce moniteur partageable, y compris avec des personnes non connectées.

Connexion

La cible étant déjà définie ci-dessus, cette section couvre comment la vérification s'authentifie et comment elle gère une tentative de connexion échouée :

• Nom d'utilisateur DB et Mot de passe utilisateur DB - les identifiants du compte de surveillance décrit ci-dessus. Les deux sont facultatifs : laissez-les vides si votre base de données autorise une connexion de confiance ou anonyme depuis une adresse autorisée, ce que font certaines configurations internes.
• Le panneau lui-même affiche les deux adresses source depuis lesquelles les vérifications sont effectuées (4.207.101.172, 20.107.152.200) avec un rappel de les inclure dans la liste d'autorisation du pare-feu de votre base de données - c'est la même exigence que celle couverte dans Avant de commencer, répétée ici car c'est exactement là où vivent les identifiants.
• Réessayer en cas d'échec de connexion - un commutateur, activé par défaut, qui retente la tentative de connexion une fois avant de marquer la vérification comme échouée. Il ne couvre que l'étape de connexion elle-même, pas la requête.

Validation de la réponse

C'est la décision clé d'une vérification Base de données : testez-vous que la connexion fonctionne, ou qu'une requête spécifique se comporte toujours comme prévu.

• Requête - laissez ce champ vide et la vérification teste uniquement la connexion : elle s'ouvre, puis se ferme, et c'est toute la vérification. Renseignez n'importe quel SQL que votre compte de surveillance est autorisé à exécuter - un SELECT, ou une instruction modifiant des données comme UPDATE, DELETE ou INSERT - et la vérification l'exécute à chaque interrogation et peut juger le résultat.
• Résultat de la requête (affiché uniquement une fois une requête saisie) - choisissez Valeur scalaire pour lire ce qui se trouve dans la première colonne de la première ligne renvoyée (le choix naturel pour un SELECT, ou pour un UPDATE/INSERT utilisant une clause OUTPUT), ou Nombre de lignes pour lire combien de lignes ont été affectées (le choix naturel pour un simple UPDATE, DELETE ou INSERT sans jeu de résultats propre).
• Vérification du résultat - une comparaison à appliquer à cette valeur : Aucune vérification (la requête doit seulement s'exécuter sans erreur), Égal à, Différent de, Supérieur à, Inférieur à, Dans la plage, ou Hors de la plage. Les options supérieur/inférieur et de plage ajoutent un ou deux champs numériques, avec un commutateur inclus/exclu sur chaque borne de plage.
• Réessayer la requête en cas d'erreur - un commutateur, activé par défaut, qui retente l'exécution de la requête une fois si elle échoue, séparément du réessai au niveau de la connexion ci-dessus.

Choisissez connexion uniquement quand vous avez simplement besoin de savoir que la base de données est joignable et accepte les connexions - cela détecte les pannes franches. Choisissez une requête avec vérification du résultat quand la seule joignabilité manquerait le vrai problème : une table qui a cessé de recevoir de nouvelles lignes, un compte stocké qui dérive hors d'une plage normale, ou une donnée spécifique qui devrait toujours être présente.

Abonnements aux alertes

Choisissez quels contacts sont informés de ce moniteur et pour quels événements - Up, Down, et Repeat (un rappel répété tant que la vérification reste en panne). Un seul commutateur abonne tous les contacts à Up/Down en une fois, ou vous pouvez choisir des contacts et des événements individuels dans le tableau en dessous.

Abonnements aux rapports

Séparément des alertes, choisissez qui reçoit les rapports périodiques de disponibilité et de performance pour ce moniteur - Quotidien, Hebdomadaire ou Mensuel - par e-mail.

Exemple concret

Surveiller une base de données PostgreSQL de production dont dépend une application : Type de serveur PostgreSQL, Serveur : Port db.example.com:5432, Base de données myapp_prod. Un compte dédié en lecture seule est saisi dans Connexion, et les deux IP source sont d'abord ajoutées au groupe de sécurité de la base de données. Le champ Requête contient SELECT COUNT(*) FROM orders WHERE created_at > now() - interval '1 hour', Résultat de la requête est Valeur scalaire, et Vérification du résultat est Supérieur à avec une limite de 0 - si aucune commande n'a été enregistrée dans la dernière heure, quelque chose en amont a cessé d'écrire, et la vérification passe en panne même si la base de données est joignable. L'intervalle est de 15 minutes, les deux commutateurs Réessayer restent activés pour qu'un incident transitoire ne déclenche pas une fausse alerte, les alertes vont vers l'abonnement Up/Down de toute l'équipe, et un rapport hebdomadaire va au propriétaire du compte.

Dépannage

• Chaque vérification échoue avec une erreur de connexion. La cause la plus courante est un pare-feu qui n'a pas été ouvert pour les deux adresses source de HostTracker - confirmez que 4.207.101.172 et 20.107.152.200 sont autorisées, et que le port lui-même leur est ouvert.
• La connexion réussit mais l'authentification échoue. Vérifiez que le nom d'utilisateur et le mot de passe DB sont corrects et que le compte a la permission de se connecter à la base de données nommée, pas seulement au serveur.
• Une requête qui fonctionne bien dans un outil client ne renvoie rien ici. Un simple UPDATE, DELETE ou INSERT sans clause OUTPUT n'a aucun jeu de résultats à lire comme Valeur scalaire - basculez Résultat de la requête sur Nombre de lignes, ou ajoutez une clause OUTPUT si vous avez besoin de récupérer les données de la ligne.
• La vérification du résultat ne se déclenche jamais. Confirmez que la comparaison et les champs numériques correspondent à la plage que vous attendez : une borne réglée sur exclue plutôt qu'incluse est un moyen facile de faire qu'une limite ne se déclenche jamais.
• Échecs isolés occasionnels que vous soupçonnez transitoires. Les deux commutateurs Réessayer sont activés par défaut et retentent déjà une fois avant de faire échouer la vérification - si les échecs restent fréquents, le problème est plus probablement une vraie difficulté de connectivité ou de requête que du bruit.

Voir aussi

• Surveillance de requêtes de base de données - la page produit pour ce type de vérification.
• Guide de la surveillance CPU, RAM et disque - une autre vérification qui s'exécute depuis l'infrastructure privée de HostTracker plutôt que depuis le réseau public, utile aux côtés d'une vérification de base de données sur le même serveur.
• Guide de la surveillance SNMP - pour lire des valeurs directement sur du matériel réseau plutôt que sur une base de données.
• Mode assertion et règles de validation de réponse - le langage de règles de validation de réponse utilisé ailleurs dans les types de vérification de HostTracker.
• Toutes les fonctionnalités de surveillance HostTracker - voir tous les types de vérification côte à côte.
• 503 Service Unavailable - le statut qu'un site renvoie quand la base de données derrière lui cesse de répondre.
• Tous les guides de surveillance - le guide de configuration pour chaque autre type de vérification.