Surveillance des bases de données Oracle

En principe, la première configuration est rapide et ne nécessite que trois étapes. La première étape consiste bien sûr à disposer d’un utilisateur autorisé à interroger les bases de données. À condition que vous n’utilisiez pas Real Application Cluster (RAC), créez un utilisateur dans chaque base de données à surveiller. La manière d'accéder à une instance varie en fonction du système d'exploitation installé. Sous Linux, vous pouvez par exemple procéder en définissant toujours au préalable l'instance concernée comme variable d'environnement dans laquelle un utilisateur doit être créé. Normalement, vous passez d'abord à l'utilisateur « oracle », mais cela peut varier en fonction de la configuration :

Connectez-vous ensuite à l'instance et créez un utilisateur pour la surveillance. Pour obtenir toutes les données, les autorisations suivantes sont requises. Dans l'exemple suivant, l'utilisateur nouvellement créé s'appelle checkmk. Vous pouvez également spécifier tout autre nom de votre choix :

Vous trouverez des informations détaillées sur le fonctionnement de la connexion à une instance spécifique dans la documentation Oracle.

Une fois que vous avez créé un utilisateur, l'étape suivante consiste à activer le plug-in de l'agent afin de recevoir ultérieurement ces informations. La méthode la plus simple consiste à définir les mêmes données de connexion pour toutes les instances et à définir une valeur par défaut dans la configuration.

L'utilisateur standard est tout ce dont le plug-in de l'agent a réellement besoin. Toutes les autres options que vous pouvez définir sur les systèmes de type Unix ou sous Windows sont facultatives.

Au lieu de spécifier directement l’utilisateur et son mot de passe dans un fichier de configuration, vous pouvez également utiliser Oracle Wallet. Cela présente l'avantage de ne plus avoir à stocker les données d'accès sous forme non chiffrée sur le serveur Checkmk et sur l'hôte Oracle. Ainsi, même si vous avez défini les droits d'accès du fichier de configuration sur l'hôte Oracle en conséquence, les données d'accès ont néanmoins quitté le serveur et se trouvent sur le serveur Checkmk tant que vous utilisez l'Agent Bakery.

Le portefeuille Oracle stocke quant à lui les données d'accès chiffrées sur l'hôte à surveiller, de sorte qu'elles puissent être utilisées sans qu'aucune donnée de connexion ne doive être divulguée explicitement. Checkmk peut ainsi utiliser ce portefeuille, de sorte que seules les données d'accès de l'administrateur de base de données (DBA) doivent être connues. Créez — ou demandez au DBA de créer — un portefeuille sur le serveur approprié :

Le plug-in de l'agent accédera à ce fichier ultérieurement chaque fois qu'une connexion à une instance devra être établie. Afin que les données utilisateur nécessaires puissent également être trouvées, vous devez les saisir une fois dans le portefeuille. Dans l'exemple suivant, vous ajoutez ainsi l'utilisateur checkmk pour l'instance MYINST1 :

Pour que le plug-in d’agent sache où rechercher le portefeuille, il doit trouver deux fichiers. Le premier fichier est sqlnet.ora, dans lequel se trouvent les informations relatives à l’emplacement du portefeuille. Le deuxième fichier — tnsnames.ora — définit l’adresse de l’instance afin qu’elle puisse également être accessible via son alias. Pour que le plug-in d’agent puisse accéder à ces fichiers, vous pouvez spécifier le chemin d’accès sous Linux, Solaris et AIX à l’aide de la variable d’environnement TNS_ADMIN. Ceci est particulièrement utile si les fichiers existent déjà. Vous pouvez également les créer explicitement. Sous Windows, vous devez même les spécifier manuellement.

Commencez par créer le fichier sqlnet.ora. Le plug-in de l'agent recherche également les données de connexion dans ce fichier ; vous devez donc y indiquer le chemin d'accès correct vers le fichier wallet que vous venez de créer. Veillez à définir le paramètre SQLNET.WALLET_OVERRIDE sur TRUE :

Le plug-in sait désormais quelles informations d'identification utiliser. Afin qu'il accède également à la bonne adresse, créez un deuxième fichier nommé tnsnames.ora. Vous trouverez la syntaxe exacte dans la documentation Oracle, mais à titre d'exemple, le fichier pourrait ressembler à ceci :

Cette étape vous a permis de créer les conditions préalables à la suppression des données d'accès du fichier de configuration du plug-in de l'agent. Au lieu des données d'accès, il vous suffit d'entrer une barre oblique (/):

Vous pouvez bien sûr ajouter ultérieurement d’autres données d’accès au portefeuille. Il suffira alors de modifier le fichier d’tnsnames.ora en conséquence.

Enfin, modifiez les permissions des fichiers et répertoires créés manuellement dans cette section afin que les droits d’accès à l’exécution soient correctement définis. Le plug-in agent exécuté en tant qu’root basculera vers le propriétaire des binaires Oracle (tels que $ORACLE_HOME/bin/sqlplus) avant de les exécuter. Au minimum, le groupe du propriétaire des binaires Oracle doit donc disposer d’un accès en lecture aux fichiers créés manuellement dans /etc/check_mk/. Dans l’exemple suivant, nous supposons que le groupe est oinstall.

Les commandes suivantes permettent de modifier le groupe en oinstall :

Ces commandes garantissent ensuite que le groupe peut lire le répertoire oracle_wallet et son contenu :

Les autorisations devraient alors ressembler à ceci :

La sortie de la commande n'affiche que les fichiers et répertoires concernés.

Une fois que vous avez créé un utilisateur lors de la configuration initiale et que vous l'avez enregistré dans le fichier de configuration, installez le plug-in de l'agent.

Lors de la configuration initiale, vous avez déjà découvert les premières variables permettant d’obtenir des données de surveillance à partir de vos instances Oracle. Cependant, selon le scénario d’application, vous aurez rapidement besoin de possibilités supplémentaires pour un contrôle individuel et optimisé de la surveillance de chaque instance. Vous trouverez ces options dans les sections suivantes. Certaines de ces options ne sont disponibles que dans les environnements de type Unix.

Sous les systèmes de type Unix, vous pouvez non seulement récupérer les instances s'exécutant localement, mais également vous connecter à des instances distantes et récupérer les bases de données qui s'y exécutent. Cela s'avère par exemple avantageux si vous n'avez pas accès au système sous-jacent, mais que vous souhaitez tout de même surveiller la base de données. Il est également possible de surveiller des bases de données distantes à partir d'un hôte sur lequel le plug-in d'agent est exécuté, mais qui ne dispose pas de base de données Oracle.

Pour surveiller des bases de données distantes, les conditions suivantes doivent être remplies sur l'hôte sur lequel le plug-in de l'agent est installé :

En règle générale, ces conditions sont déjà remplies s’il existe une installation Oracle sur l’hôte. Sinon, installez les paquets appropriés pour y remédier.

Pour que le plug-in de l'agent puisse se connecter à la base de données distante, enregistrez d'abord les données d'accès dans le fichier de configuration. Celles-ci sont similaires aux spécifications d'DBUSER, que vous avez déjà rencontrées lors de la configuration utilisateur avancée. Il existe toutefois un certain nombre de spécifications obligatoires supplémentaires :

Dans l’exemple, deux instances distantes sont configurées à l’aide de deux lignes. Afin que chaque ligne de texte soit unique, un identifiant est défini à la fin de chaque variable. Vous pouvez les choisir librement — elles doivent simplement être uniques pour chaque fichier de configuration. Comme vous l’avez sans doute déjà remarqué, la spécification du port est désormais suivie d’autres valeurs. Celles-ci sont en partie facultatives et en partie nécessaires pour établir une connexion.

La première nouvelle valeur PIGGYBACKHOST est définie sur myOracleHost pour l’instance MYINST3. Cette spécification attribue les résultats de la requête, via le mécanisme de piggyback, à l’hôte spécifié. Si celui-ci est présent en tant qu’hôte dans Checkmk, les nouveaux services y apparaîtront en conséquence, plutôt que sur l’hôte où le plug-in de l’agent est en cours d’exécution ou à partir duquel les données ont été récupérées. Vous ne voyez pas cette spécification sur la deuxième instance MYINST1 — l’attribution à un autre hôte est facultative.

La deuxième nouvelle valeur SID est le nom de l'instance. Étant donné que le plug-in de l'agent ne peut pas voir quelles instances s'exécutent sur l'hôte distant, une ligne de configuration doit être spécifiée pour chaque instance distante — cette valeur est donc obligatoire et n'est donc pas facultative.

La troisième valeur VERSION est obligatoire et s’explique également par le fait que de nombreuses métadonnées ne sont disponibles que si vous êtes directement sur l’hôte. Par conséquent, la spécification de version ne peut pas non plus être omise, et celle-ci détermine quelles requêtes SQL peuvent être transmises à l’instance. Dans l’exemple, les deux instances distantes utilisent la version 11.2.

La quatrième et dernière valeur d'TNSALIAS est à nouveau facultative et peut être utilisée si vous accédez à l'instance distante via Oracle Wallet ou LDAP/Active Directory. Dans le cas où l'instance ne répondrait qu'à un alias TNS spécifique, vous pouvez spécifier cet alias ici. Pour la deuxième instance distante, TNSALIAS a pour valeur INST1.

Pour vous assurer que le programme sqlplus est également détecté, utilisez la variable REMOTE_ORACLE_HOME pour indiquer l'emplacement du client Oracle sur l'hôte qui exécute le plug-in de l'agent. Ce n'est qu'alors que toutes les ressources nécessaires aux requêtes seront disponibles.

Lors de l'interrogation d'instances distantes, certaines restrictions et fonctionnalités particulières s'appliquent :

Dans la configuration la plus simple pour un système d'exploitation de type Unix, la règle ressemblera à ceci :

Dans l’Agent Bakery, vous avez également la possibilité de créer des utilisateurs standard et de définir des exceptions pour des instances spécifiques. Les options séparées par des deux-points (pour Linux & Co.) ou sous forme d’entrées de liste (pour Windows) dans le fichier de configuration se trouvent sous Login Defaults en tant qu’options individuelles, que vous pouvez ensuite remplir en conséquence. Bien entendu, vous pouvez également utiliser Oracle Wallet ici en remplaçant simplement Authentication method par Use manually created Oracle password wallet.

Vous pouvez configurer la gestion automatique du stockage (ASM) de la même manière à l'aide de l'option Login for ASM, et saisir les exceptions pour des instances spécifiques sous Login for selected databases, comme décrit dans la configuration utilisateur avancée.

Le tableau suivant répertorie les autres options du jeu de règles « Oracle databases (Linux, Solaris, AIX, Windows) », ainsi qu’une référence indiquant où trouver une description de l’option :

Oracle prend en charge ce que l'on appelle des bases de données de secours, qui peuvent effectuer des tâches spécifiques et qui sont généralement de simples copies des bases de données de production ou primaires. Ces concepts de base de données nécessitent également des mécanismes de surveillance spécifiques. Vous trouverez plus d'informations sur ces mécanismes dans les sections suivantes.

Comme il existe un stockage centralisé des données dans un RAC, il suffit ici de créer l’utilisateur pour le plug-in de l’agent une seule fois. Seul le plug-in de l’agent doit être installé et configuré sur chaque nœud du cluster Oracle.

Important : configurez toujours vous-même les nœuds du cluster et n’interrogez pas le listener Oracle SCAN. C’est le seul moyen de garantir le bon fonctionnement de l’accès via le plug-in de l’agent.

Grâce à son plug-in d'agent, Checkmk fournit déjà un grand nombre de requêtes SQL permettant de surveiller vos instances de base de données. Afin de les adapter au plus grand nombre possible d'exigences techniques et de contenu, celles-ci sont bien sûr conservées sous une forme très générale.

Afin de pouvoir répondre aux exigences individuelles de chaque entreprise en matière de surveillance d’une base de données spécifique, Checkmk offre la possibilité de créer vos propres requêtes SQL personnalisées (ou « custom SQLs ») et de les récupérer via le plug-in agent. Ces requêtes SQL personnalisées sont ensuite automatiquement reconnues et surveillées en tant que services distincts dans l’interface Web.

Les possibilités de surveillance à l'aide de requêtes SQL personnalisées vont bien sûr au-delà du simple exemple présenté ci-dessus. Vous trouverez ci-dessous un aperçu des variables disponibles que vous pouvez utiliser dans le fichier de configuration mk_oracle.cfg. Pour une description détaillée, vous pouvez également appeler le plug-in de l'agent mk_oracle avec l'option --help.

Si les possibilités offertes par la syntaxe décrite ci-dessus ne sont pas suffisantes, vous pouvez également utiliser la variable SQLS_SECTION_NAME pour générer vos propres noms de section pour une ou plusieurs requêtes SQL et définir votre propre séparateur avec SQLS_SECTION_SEP. Cela nécessite toutefois que vous ayez également écrit un plug-in de vérification approprié et que vous l'ayez intégré à votre site Checkmk.

Si vous avez écrit un tel plug-in de vérification, vous êtes entièrement libre d'évaluer la sortie des sections personnalisées du plug-in d'agent et pouvez procéder à votre guise. Comme cette méthode est la plus complète, mais aussi la plus difficile, elle n’est mentionnée ici que par souci d’exhaustivité. Elle suppose que vous sachiez comment écrire un plug-in de contrôle basé sur un agent et l’intégrer au site. Ensuite, vous attribuez les requêtes SQL personnalisées avec les variables à ce plug-in de contrôle.

Si vous rencontrez des problèmes pour vous connecter à une ou plusieurs instances sur un serveur Oracle, la première chose à faire est de vérifier les paramètres de base.

Le test de connexion décrit ci-dessous vérifie également si les droits d'accès nécessaires sont définis lors de l'exécution. Si des droits d'accès font défaut, ceux-ci sont affichés avec des suggestions spécifiques pour y remédier. La procédure exacte pour diagnostiquer et corriger les droits d'accès est disponible dans la base de connaissances Checkmk.

Si l'erreur ne peut être identifiée par une simple vérification de la connexion, l'étape suivante consiste à créer un fichier journal qui consigne toutes les étapes du plug-in de l'agent.

Vous pouvez utiliser les messages de journal générés pour identifier très précisément sur quelle ligne du script le problème s'est produit.

Si vous ne parvenez pas à identifier le problème, même à l'aide du journal, le plug-in de l'agent fournit, en dernier recours, la sortie complète de toutes les étapes pour l'analyse des erreurs. Cette sortie est donc la méthode la plus complète, et certainement la plus difficile à lire, pour déterminer la cause d'un problème ; elle ne doit donc être utilisée qu'en dernier recours.

L'utilisateur de la base de données chargé de la surveillance n'a généralement pas besoin du rôle « SYSDBA ». Notez toutefois que l'mk_oracle du plug-in de l'agent peut générer des messages d'erreur (sans incidence sur la surveillance) avec des bases de données multi-locataires, qui peuvent ne pas être consignés dans les fichiers journaux de la base de données Oracle en raison de l'absence du privilège « SYSDBA ». Cela peut alors entraîner, par exemple, l'apparition de messages d'erreur Oracle de type « ORA-01031: insufficient privileges » dans un fichier journal d'alerte.