Oracle-Datenbanken überwachen

Prinzipiell ist die erste Einrichtung schnell und in nur drei Schritten erledigt. Der erste Schritt ist natürlich, sicherzustellen, dass es einen Benutzer gibt, welcher die Datenbanken auch abfragen darf. Sofern Sie keinen Real Application Cluster (RAC) nutzen, legen Sie dafür in jeder zu überwachenden Datenbank einen Benutzer an. Wie Sie sich auf einer Instanz anmelden, unterscheidet sich je nachdem, welches Betriebssystem Sie einsetzen. Für Linux können Sie das zum Beispiel erledigen, indem Sie zuerst immer die jeweilige Instanz als Umgebungsvariable setzen, in der Benutzer angelegt werden soll. Normalerweise wechselt man dafür zuvor auf den oracle-Benutzer. Das kann sich aber je nach Setup unterscheiden:

Danach melden Sie sich bei der Instanz an und legen einen Benutzer für das Monitoring an. Um an alle Daten zu kommen, werden auch die nachfolgenden Berechtigungen benötigt. In dem folgendem Beispiel heißt der neu angelegte Benutzer checkmk. Sie können auch jeden anderen Namen wählen:

Wie die Anmeldung an einer bestimmten Instanz genau funktioniert, können Sie in der Oracle-Dokumentation nachlesen.

Nachdem Sie einen Benutzer angelegt haben, sorgen Sie als Zweites dafür, dass das Agentenplugin später diese Informationen auch bekommt. Die einfachste Möglichkeit ist es dann, wenn Sie für alle Instanzen die gleichen Login-Daten gesetzt haben und einen Standard in der Konfiguration setzen können.

Der Standardbenutzer ist das Einzige, was das Agentenplugin zwingend benötigt. Alle anderen Einstellungen, die Sie unter Unix-artigen Systemen oder unter Windows verwenden können, sind optional.

Alternativ dazu, den Benutzer direkt und mit Passwort in einer Konfigurationsdatei anzugeben, können Sie auch das Oracle-Wallet nutzen. Das hat den Vorteil, dass Sie nicht mehr die Zugangsdaten unverschlüsselt sowohl auf dem Checkmk-Server als auch auf dem Oracle-Host ablegen müssen. Denn selbst wenn Sie die Rechte der Konfigurationsdatei auf dem Oracle-Host entsprechend angepasst haben, haben die Zugangsdaten dennoch den Server verlassen und befinden sich auf dem Checkmk-Server, sofern Sie die Agentenbäckerei nutzen.

Das Oracle-Wallet wiederum legt die Zugangsdaten verschlüsselt auf dem zu überwachenden Host ab, sodass sie benutzt werden können, aber keine Login-Daten explizit bekannt gemacht werden müssen. Checkmk kann dieses Wallet nutzen, sodass die Zugangsdaten prinzipiell nur dem Datenbankadministrator (DBA) bekannt sein müssen. Dazu legen Sie — oder der DBA — ein Wallet auf dem entsprechenden Server an:

Auf diese Datei wird das Agentenplugin später immer dann zugreifen, wenn eine Verbindung zu einer Instanz hergestellt werden soll. Damit die nötigen Benutzerdaten auch gefunden werden, müssen Sie diese einmalig in das Wallet eintragen. In dem folgenden Beispiel fügen Sie also den Benutzer checkmk für die Instanz MYINST1 hinzu:

Damit das Agentenplugin weiß, wo es nach dem Wallet suchen muss, muss es zwei Dateien finden. Die erste Datei ist sqlnet.ora in welcher hinterlegt wird, wo das Wallet zu finden ist. Die zweite Datei — tnsnames.ora — bestimmt die Adresse der Instanz, sodass diese auch über ihren Alias angesprochen werden kann. Damit das Agentenplugin diese Dateien findet, können Sie den Pfad unter Linux, Solaris und AIX über die Umgebungsvariable TNS_ADMIN setzen. Das ist vor allem dann von Vorteil, wenn die Dateien bereits existieren. Alternativ können Sie sie auch explizit anlegen. Unter Windows ist es sogar erforderlich, dass Sie diese manuell bestimmen.

Legen Sie zunächst die Datei sqlnet.ora an. In dieser Datei sucht das Agentenplugin alternativ nach den Zugangsdaten, sodass hier also der korrekte Pfad zu der eben erstellten Wallet-Datei angegeben werden muss. Achten Sie dabei darauf, dass Sie den Parameter SQLNET.WALLET_OVERRIDE auf TRUE setzen:

Jetzt weiß das Plugin, welche Zugangsdaten benutzt werden sollen. Damit es auch die korrekte Adresse ansteuert, legen Sie als Datei die tnsnames.ora an. Die genaue Syntax können Sie der Oracle-Dokumentation entnehmen, aber als Beispiel könnte die Datei so aussehen:

Mit diesem Schritt haben Sie die Voraussetzungen geschaffen, um die Zugangsdaten aus der Konfigurationsdatei des Agentenplugins herauszunehmen. Statt den Zugangsdaten tragen Sie lediglich ein / (Schrägstrich) ein:

Sie können dem Wallet natürlich zu einem späteren Zeitpunkt weitere Zugangsdaten hinzufügen. Lediglich die Datei tnsnames.ora muss dann gegebenenfalls erweitert werden.

Zum Abschluss ändern Sie die Berechtigungen der in diesem Abschnitt manuell erstellten Dateien und Verzeichnisse, damit die Zugriffsrechte bei der Ausführung richtig gesetzt sind. Das Agentenplugin, das als root ausgeführt wird, wechselt zum Eigentümer der Oracle-Binärdateien (z.B. $ORACLE_HOME/bin/sqlplus), bevor es diese ausführt. Zumindest die Gruppe des Eigentümers der Oracle-Binärdateien benötigt daher lesenden Zugriff auf die manuell erstellten Dateien in /etc/check_mk/. Im folgenden Beispiel nehmen wir an, dass es sich bei der Gruppe um oinstall handelt.

Die folgenden Befehle ändern die Gruppe zu oinstall:

Diese Befehle stellen dann sicher, dass die Gruppe das Verzeichnis oracle_wallet samt Inhalt lesen kann:

Anschließend sollten die Berechtigungen etwa wie folgt aussehen:

Die Befehlsausgabe zeigt nur die Dateien und Verzeichnisse, um die es geht.

Nachdem Sie bei der Ersteinrichtung einen Benutzer angelegt und diesen in der Konfigurationsdatei hinterlegt haben, installieren Sie nun noch das Agentenplugin.

In der Ersteinrichtung haben Sie bereits erste Variablen kennengelernt, um Überwachungsdaten von Ihren Oracle-Instanzen zu bekommen. Je nach Anwendungsszenario werden Sie aber schnell weitere Möglichkeiten benötigen, um die Überwachung besser und individuell pro Instanz steuern zu können. Diese Optionen finden Sie in den nachfolgenden Abschnitten. Einige der Optionen stehen Ihnen nur in Unix-artigen Umgebungen zur Verfügung.

Unter Unix-artigen Systemen können Sie nicht nur lokal laufende Instanzen abrufen, sondern sich auch auf entfernten anmelden und die dort laufenden Datenbanken abrufen. Dies ist zum Beispiel dann von Vorteil, wenn Sie keinen Zugriff auf das darunter liegende System haben, aber die Datenbank dennoch überwachen wollen. Auch ist es möglich, entfernte Datenbanken von einem Host aus zu überwachen, auf dem zwar das Agentenplugin aber keine Oracle Datenbank läuft.

Um entfernte Datenbanken zu überwachen, müssen auf dem Host, auf dem das Agentenplugin installiert ist, die folgenden Voraussetzungen erfüllt sein:

In der Regel sind die Voraussetzungen schon erfüllt, wenn sich auf dem Host eine Oracle-Installation befindet. Andernfalls holen Sie die Installation der entsprechenden Pakete nach.

Damit sich das Agentenplugin mit der entfernten Datenbank verbinden kann, hinterlegen Sie zunächst in der Konfigurationsdatei die Zugangsdaten. Diese sind ähnlich zu den Angaben für DBUSER, die Sie bereits in der erweiterten Benutzerkonfiguration kennengelernt haben. Allerdings gibt es zusätzlich noch eine Reihe mehr an verpflichtenden Angaben:

Im Beispiel sind zwei entfernte Instanzen konfiguriert in zwei Zeilen. Damit jede Zeile eindeutig ist, wird am Ende jeder Variablen eine ID festgelegt. Diese können Sie frei wählen, sie muss lediglich pro Konfigurationsdatei eindeutig sein. Wie Sie wahrscheinlich schon bemerkt haben, folgen auf die Angabe des Ports nun weitere Werte. Diese sind teilweise optional und teilweise notwendig, um eine Verbindung aufbauen zu können:

Der erste neue Wert PIGGYBACKHOST ist bei der Instanz MYINST3 gesetzt auf myOracleHost. Durch diese Angabe werden die Ergebnisse für die Abfrage durch den Piggyback-Mechanismus dem angegebenen Host zugeordnet. Ist dieser in Checkmk als Host vorhanden, werden die neuen Services entsprechend dort erscheinen, anstatt auf dem Host, auf dem das Agentenplugin läuft, bzw. von dem aus die Daten geholt wurden. Auf der zweiten Instanz MYINST1 sehen Sie diese Angabe nicht — die Zuordnung zu einem anderen Host ist optional.

Der zweite neue Wert SID ist die Angabe des Instanznamens. Da das Agentenplugin nicht schauen kann, welche Instanzen auf dem entfernten Host laufen, muss für jede entfernte Instanz eine Konfigurationszeile angegeben werden — der Wert ist also notwendig und damit nicht optional.

Der dritte Wert VERSION ist notwendig und ebenfalls dem Umstand geschuldet, dass viele Metadaten nur zur Verfügung stehen, wenn man sich direkt auf dem Host befindet. Die Versionsangabe kann daher auch nicht weggelassen werden und bestimmt, welche SQL-Abfragen an die Instanz übergeben werden können. Im Beispiel verwenden beide entfernten Instanzen die Version 11.2.

Der vierte und letzte Wert TNSALIAS ist wieder optional und kann verwendet werden, wenn Sie auf die entfernte Instanz per Oracle Wallet oder LDAP/Active Directory zugreifen möchten. Für den Fall, dass die Instanz dann nur auf einen bestimmten TNS-Alias antwortet, können Sie diesen hier angeben. Für die zweite entfernte Instanz hat TNSALIAS den Wert INST1.

Damit auch das Programm sqlplus gefunden wird, geben Sie schließlich mit der Variablen REMOTE_ORACLE_HOME an, wo sich der Oracle-Client auf dem Host befindet, der das Agentenplugin ausführt. Nur dann sind alle Ressourcen verfügbar, die für die Abfragen benötigt werden.

Bei der Abfrage von entfernten Instanzen gelten ein paar Einschränkungen und Besonderheiten:

In der einfachsten Konfiguration für eines der Unix-artigen Betriebssysteme sieht die Regel etwa so aus:

Auch in der Agentenbäckerei haben Sie die Möglichkeit, Standardbenutzer und Ausnahmen für spezielle Instanzen anzulegen. Die Optionen, die in der Konfigurationsdatei mit Doppelpunkt (für Linux & Co.) oder als Listeneinträge (für Windows) separiert sind, finden Sie unter Login Defaults als einzelne Optionen, die Sie dann entsprechend ausfüllen. Natürlich können Sie auch hier das Oracle Wallet nutzen, indem Sie bei Authentication method einfach auf Use manually created Oracle password wallet wechseln.

Die Konfiguration für ein Automatic Storage Management (ASM) erledigen Sie analog über die Option Login for ASM, und die Ausnahmen für spezifische Instanzen tragen Sie bei Login for selected databases ein, so wie es bei der erweiterten Benutzerkonfiguration beschrieben ist.

In der folgenden Tabelle finden Sie die restlichen Optionen des Regelsatzes Oracle databases (Linux, Solaris, AIX, Windows) zusammen mit einem Verweis darauf, wo Sie eine Beschreibung zu der Option finden:

Oracle unterstützt sogenannte Standby-Datenbanken, welche bestimmte Aufgaben erfüllen können und in der Regel schlicht Kopien von produktiven bzw. primären Datenbanken sind. Diese Datenbankkonzepte benötigen auch spezielle Mechanismen in der Überwachung. Welche das sind, erfahren Sie in den folgenden Abschnitten.

Da es in einem RAC einen zentralen Speicher für die Daten gibt, reicht es hier, den Benutzer für das Agentenplugin nur einmal anzulegen. Lediglich das Agentenplugin muss auf jedem Knoten des Oracle-Clusters installiert und konfiguriert werden.

Wichtig: Richten Sie immer die Knoten des Clusters selbst ein und verzichten Sie auf die Abfrage des Oracle SCAN Listener. Nur dadurch ist gewährleistet, dass der Zugriff über das Agentenplugin funktioniert.

Checkmk bietet mit dem Agentenplugin bereits eine große Menge an SQL-Abfragen, mit denen Sie Ihre Datenbankinstanzen überwachen können. Damit diese für eine möglichst große Menge an technischen und inhaltlichen Anforderungen passend sind, sind diese natürlich sehr allgemein gehalten.

Um die individuellen Anforderungen eines jeden Unternehmens an die Überwachung einer konkreten Datenbank erfüllen zu können, bietet Checkmk die Möglichkeit, eigene, benutzerdefinierte SQL-Abfragen (Custom SQLs) zu erstellen und mit dem Agentenplugin abfragen zu lassen. Diese werden dann automatisch in der Weboberfläche als eigene Services erkannt und überwacht.

Die Möglichkeiten, mit benutzerdefinierten SQL-Abfragen zu überwachen, gehen natürlich über das einfache, oben gezeigte Beispiel hinaus. Im nachfolgenden finden Sie eine Übersicht der verfügbaren Variablen, die Sie in der Konfigurationsdatei mk_oracle.cfg nutzen können. Für eine ausführliche Beschreibung können Sie auch das Agentenplugin mk_oracle mit der Option --help aufrufen.

Sollten Ihnen die Möglichkeiten der oben beschriebenen Syntax nicht ausreichen, können Sie über die Variable SQLS_SECTION_NAME auch eigene Sektionsnamen für ein oder mehrere SQL-Abfragen ausgeben lassen, und mit SQLS_SECTION_SEP einen eigenen Separator festlegen. Das setzt allerdings voraus, dass Sie auch ein entsprechendes Check-Plugin geschrieben und in Ihre Checkmk-Instanz eingebunden haben.

Mit einem eigenen Check-Plugin sind Sie komplett frei, wie Sie die Ausgabe der selbst definierten Sektionen des Agentenplugins auswerten und können ganz eigene Wege gehen. Da dieser Weg der umfangreichste und auch schwierigste ist, ist er hier nur der Vollständigkeit halber erwähnt. Er setzt voraus, dass Sie wissen, wie man ein agentenbasiertes Check-Plugin schreibt und in die Instanz einbindet. Danach ordnen Sie die individuellen SQL-Abfragen mit den Variablen diesem Check-Plugin zu.

Sollten Sie Probleme mit der Verbindung zu einer oder mehreren Instanzen auf einem Oracle-Server haben, können Sie als Erstes grundlegende Parameter prüfen lassen.

Der im Folgenden beschriebene Verbindungstest überprüft auch, ob die notwendigen Zugriffsrechte bei der Ausführung gesetzt sind. Falls Zugriffsrechte fehlen, werden diese angezeigt mit konkreten Vorschlägen zur Behebung. Das genaue Vorgehen bei der Diagnose und Korrektur von Zugriffsrechten können Sie in der Checkmk Knowledge Base nachlesen.

Falls der Fehler nicht durch die Prüfung einer einfachen Verbindung gefunden werden kann, können Sie als nächsten Schritt eine Log-Datei anlegen lassen, welche sämtliche Schritte des Agentenplugins protokolliert.

Mit Hilfe der erzeugten Log-Meldungen können Sie sehr genau identifizieren, an welcher Zeile des Skripts das Problem auftritt.

Wenn Sie auch mit Hilfe des Logs nicht an das Problem kommen, bietet das Agentenplugin als letzte Möglichkeit der Fehleranalyse die komplette Ausgabe aller Schritte. Diese Ausgabe ist entsprechend auch die umfangreichste und sicherlich auch die am schwersten zu lesende Möglichkeit, an die Ursache eines Problems zu kommen, und sollte daher auch nur als letztes Mittel eingesetzt werden.

Der Datenbankbenutzer für das Monitoring benötigt in der Regel nicht die Rolle SYSDBA. Beachten Sie aber, dass das Agentenplugin mk_oracle bei Multi-Tenant-Datenbanken (für das Monitoring nicht relevante) Fehlermeldungen erzeugen kann, die eventuell wegen der fehlenden SYSDBA-Berechtigung nicht in Log-Dateien der Oracle-Datenbank geschrieben werden können. Dies kann dann z.B. zu Oracle-Fehlermeldungen der Art ORA-01031: insufficient privileges in einer Alert-Log-Datei führen.