Oracle-Datenbanken überwachen

Man kann auch den Login für Multi-Tenant-Datenbanken konfigurieren. Das wird normalerweise mit einem speziellen Benutzer und in der Konfiguration mit dem Präfix C## durchgeführt. Die Berechtigungsvergabe unterscheidet sich jedoch leicht von der Anleitung für normale Benutzer, da Sie diese für alle jetzigen und zukünftigen Container festlegen:

Mit dem Standard-Login können Sie reguläre oder vielleicht sogar alle Instanzen einer Datenbank abfragen. Es gibt jedoch Sonderfälle, in denen Sie für einzelne Instanzen individuelle Zugangsdaten benötigen. In der Konfigurationsdatei haben Sie daher die folgenden drei Möglichkeiten, Benutzer anzugeben:

Zusätzlich erlauben diese Variablen noch mehr Optionen außer Benutzername und Passwort. Sie können auch bestimmen, ob es sich bei dem Benutzer um einen SYSDBA oder SYSASM handelt, auf welcher Kombination von Adresse und Port die Instanz lauscht und sogar, welcher TNS-Alias (TNSALIAS) benutzt werden soll. Diese Angaben sind aber immer — im Gegensatz zu Benutzer und Passwort — optional. Zusätzlich zu dem obigen Beispiel kann eine Konfiguration dann so aussehen:

Ein paar Erläuterungen zu dem Beispiel:

In manchen Fällen wollen Sie bestimmte Instanzen nicht in die Überwachung mit einbeziehen. Das kann zum Beispiel sein, weil es nur eine Spielwiese für Entwickler ist. Um die Konfiguration im Einzelfall möglichst einfach zu machen, haben Sie verschiedene Möglichkeiten, um eine oder mehrere Instanzen ganz oder teilweise auszuschließen:

Sie werden es schon ahnen: Die Reihenfolge der Verarbeitung dieser Parameter bestimmt das Ergebnis. Tatsächlich werden die Angaben auch genau in der Reihenfolge pro Instanz verarbeitet, wie sie in der obigen Tabelle angegeben sind. Wenn also die Variable ONLY_SIDS gesetzt ist, wird SKIP_SIDS gar nicht mehr ausgewertet und auch nicht mehr, ob es eine Angabe der Variable EXCLUDE_<SID> auf ALL für diese Instanz gibt. Ist ONLY_SIDS nicht gesetzt, geht es dann entsprechend der Reihenfolge weiter. Im Zweifel — also als Standardverhalten — wird die Instanz entsprechend überwacht.

Am nachfolgenden Beispiel erläutern wir das Verhalten, falls alle Variablen gesetzt sind:

Da die positive Liste aus der ersten Zeile immer bevorzugt wird, wird die zweite und dritte Zeile nicht mehr ausgewertet. Lediglich die vierte (letzte) Zeile wird zu einem späteren Zeitpunkt berücksichtigt, da hier die Instanz nur teilweise ausgewertet werden soll.

In der Praxis ist es also sinnvoll nur eine der Variablen zu nutzen, um die Menge der zu überwachenden Instanzen zu bestimmen.

Wie Sie bereits im vorherigen Abschnitt gelernt haben, können Sie Instanzen nicht nur komplett ausschließen, sondern auch lediglich teilweise überwachen. Die Einsatzzwecke sind vielfältig und vor allem dann sinnvoll, wenn Sie bestimmte, lang laufende Sektionen nicht überall berücksichtigen wollen oder auf Testinstanzen nur grundlegende Informationen benötigen. Um Sektionen global einzuschränken, setzen Sie die entsprechenden Variablen direkt. Um nur bestimmte Instanzen einzuschränken, können Sie die Variable EXCLUDE_<SID> nutzen, die Sie im vorherigen Abschnitt bereits kennengelernt haben. Die globalen Variablen sind:

Der Mechanismus erlaubt es demnach, in der Konfigurationsdatei einen Standard zu setzen und diesen bei Bedarf je Instanz zu überschreiben. Eine Konfiguration könnte dann zum Beispiel so aussehen:

Wie Sie in dem Beispiel sehen, wird für die ASM-Instanzen lediglich die Sektion instance abgefragt und auf allen regulären Instanzen ein Minimalset für die asynchronen Sektionen angegeben. Zusätzlich wird auf der Instanz INST1 auf die synchronen Sektionen undostat und locks verzichtet. Da die synchronen Sektionen nicht explizit angegeben wurden, werden auf allen anderen Instanzen alle synchronen Sektionen abgerufen. Bei der Instanz INST2 wiederum werden nur drei der vier asynchronen Sektionen abgefragt, da jobs zusätzlich ausgeschlossen wurde. Und schließlich wird der Cache von 10 Minuten auf 5 Minuten (300 Sekunden) heruntergesetzt, da es möglich ist, alle Daten in diesem Zeitraum zu holen.

Wollen Sie zum Beispiel nur locks aus der synchronen Abfrage herausnehmen, geben Sie die gesamte synchrone Liste an und lassen Sie lediglich locks weg:

Gleiches gilt auch für die anderen drei Variablen, in denen die Sektionen bestimmt werden.

Der TNS-Alias ist ein benutzerfreundlicher Name für eine Datenbankverbindung. Dabei steht TNS für die Oracle-Netzwerktechnologie Transparent Network Substrate. Ein TNS-Alias ermöglicht es, eine Verbindung zu einer Datenbankinstanz herzustellen, ohne jedes Mal die vollständigen Verbindungsdetails (wie Host-Name, Port-Nummer oder Service-Name) angeben zu müssen. TNS-Alias werden in der Datei tnsnames.ora festgelegt. Der Abschnitt zur Oracle-Wallet enthält ein Beispiel zur Festlegung eines TNS-Alias.

TNS_ADMIN ist eine Umgebungsvariable, die auf das Verzeichnis zeigt, in dem sich Oracle-Konfigurationsdateien wie sqlnet.ora und tnsnames.ora befinden. Standardmäßig wird TNS_ADMIN von Oracle auf $ORACLE_HOME/network/admin gesetzt. In der Konfigurationsdatei können Sie TNS_ADMIN einen anderen Pfad zuweisen, wie im folgenden Beispiel für eine konkrete Oracle-Installation:

Nur falls die Variable gar nicht gesetzt ist, wird sie vom Agentenplugin auf /etc/check_mk/ gesetzt.

Aus Sicherheitsgründen führt das Agentenplugin mk_oracle Oracle-Binärprogramme nicht länger unter dem Benutzer root aus. Das betrifft die Programme sqlplus, tnsping und — falls vorhanden — crsctl. Stattdessen wechselt mk_oracle zum Beispiel zum Eigentümer der Datei $ORACLE_HOME/bin/sqlplus, bevor es sqlplus ausführt. Dies stellt sicher, dass Oracle-Programme nur noch von einem nicht privilegierten Benutzer ausgeführt werden und verhindert so, dass ein böswilliger Oracle-Benutzer ein Binärprogramm wie sqlplus ersetzen und als root-Benutzer ausführen lassen kann.

Die Ausführung der Oracle-Programme durch einen nicht privilegierten Benutzer kann zu Problemen bei der Verwendung eines Oracle-Wallet führen, da dieser Benutzer möglicherweise nicht auf die Wallet-spezifischen Dateien zugreifen kann. Der nicht privilegierte Benutzer benötigt die Berechtigungen zum Lesen der Dateien $TNS_ADMIN/sqlnet.ora und $TNS_ADMIN/tnsnames.ora, zum Ausführen des Wallet-Ordners und zum Lesen der Dateien im Wallet-Ordner. Sie sollten keine Probleme mit den Zugriffsrechten haben, sofern Sie Eigentümer und Gruppe der Dateien und Verzeichnisse so geändert haben, wie es am Ende des Abschnitts zur Oracle-Wallet beschrieben ist.

Das Agentenplugin hilft Ihnen bei der Diagnose und überprüft, ob es Probleme beim Zugriff auf die genannten Dateien gibt und zeigt diese beim Verbindungstest an. Das genaue Vorgehen bei der Diagnose und Korrektur von Zugriffsrechten können Sie in der Checkmk Knowledge Base nachlesen.

Wie unter Linux können Sie auch bei dem Windows-Agentenplugin nicht nur ein Standard-Login definieren, sondern auch individuelle Zugangsdaten für einzelne Instanzen Sie haben also die gleichen drei Möglichkeiten, Benutzer anzugeben:

Zusätzlich können auch hier noch mehr Optionen außer Benutzername oder Passwort angegeben werden. Diese zusätzlichen Angaben sind ebenfalls optional. Allerdings muss jede Angabe ausgefüllt werden, wenn sie benutzt wird. Eine Konfiguration kann dann zum Beispiel so aussehen:

Ein paar Erläuterungen zu dem Beispiel:

Auch unter Windows möchte man bestimmte Instanzen nicht immer einbeziehen. Gründe dafür wurden im Abschnitt für Linux bereits beschrieben. Zwei der drei Parameter für Linux können Sie auch bei Windows verwenden:

Die Verarbeitung erfolgt pro Instanz in der Reihenfolge, wie in der obigen Tabelle angegeben. Es wird also zuerst geprüft, ob sich die Instanz in ONLY_SIDS befindet und erst danach, ob bestimmte Sektionen ausgeschlossen werden sollen. Ist die Variable EXCLUDE_<SID> auf ALL gesetzt, so wird auch keine Sektion ausgeführt.

Nachfolgend ein Beispiel, bei dem beide Variablen einmal gezeigt werden:

Beachten Sie, dass es sich bei ONLY_SIDS um eine Liste handelt, bei EXCLUDE_INST1 hingegen um einen String, der durch Leerzeichen separierte Sektionen enthält.

Die Festlegung, welche Sektionen überhaupt zu holen sind, erfolgt äquivalent zu Linux. Daher hier nur ein Beispiel der Konfiguration für Windows:

Wollen Sie zum Beispiel nur locks aus der synchronen Abfrage herausnehmen, geben Sie die gesamte synchrone Liste an und lassen Sie lediglich locks weg:

Gleiches gilt auch für die anderen drei Variablen, in denen die Sektionen bestimmt werden.

Aus Sicherheitsgründen führt das Agentenplugin mk_oracle.ps1 Oracle-Binärprogramme nur noch dann als Administrator aus, wenn diese Programme auch nur von Administratoren verändert werden können. Als Administratoren unter Windows gelten dabei das lokale Systemkonto (Local System) und Mitglieder der eingebauten Gruppe Administrators. Das betrifft die Programme sqlplus.exe, tnsping.exe und — falls vorhanden — crsctl.exe. Das Agentenplugin mk_oracle.ps1 führt keines dieser Programme aus, wenn nicht-administrative Benutzer eine der Berechtigungen Write, Modify oder Full control für die Datei haben. Dies verhindert das Sicherheitsrisiko der Ausführung von Programmen nicht privilegierter Benutzer als Administrator.

Ändern Sie gegebenenfalls die Zugriffsrechte, indem Sie die oben genannten Berechtigungen nicht-administrativer Benutzer für die Programme entfernen. Das Agentenplugin hilft Ihnen bei der Diagnose und überprüft, ob nicht-administrative Benutzer Zugriff auf die genannten Dateien haben und zeigt diese beim Verbindungstest an. Das genaue Vorgehen bei der Diagnose und Korrektur von Zugriffsrechten können Sie in der Checkmk Knowledge Base nachlesen.

Falls es bei Ihnen nicht möglich ist, die Berechtigungen für die Oracle-Programme sicher anzupassen, können Sie einzelnen Benutzern und Gruppen die Ausführung der Programme erlauben:

Nur wenn es keine andere Möglichkeit gibt, die Überwachung von Oracle sicherzustellen, können Sie als letzte Option die Überprüfung der Zugriffsrechte abschalten.

Es gibt aber auch noch einen anderen Weg, das Agentenplugin auszuführen — und zwar ganz ohne Administratorrechte. So können Sie die Ausführung des Agentenplugins anpassen und es zum Beispiel unter der lokalen Windows-Gruppe Users ausführen lassen. Dazu bearbeiten Sie die Konfigurationsdatei check_mk.user.yml des Windows-Agenten, zum Beispiel so:

In den kommerziellen Editionen können Sie sich diese Einträge mit der Agentenregel Run plug-ins and local checks using non-system account von der Agentenbäckerei erstellen lassen.

Haben Sie ADG lizenziert und aktiviert, müssen Sie keinerlei Veränderungen in der Konfiguration des Agentenplugins vornehmen, da Sie jederzeit von einer Standby-Instanz lesen können, ohne die Synchronisation mit der primären Instanz unterbrechen zu müssen.

Wenn die Instanzen nicht über ADG verfügen, benötigt der Benutzer, mit dem die Monitoring-Daten der Standby-Instanzen geholt werden sollen, die Rolle SYSDBA. Durch diese Berechtigung ist der Benutzer auch dann in der Lage zumindest einen Teil der Daten zu holen, wenn die primäre Instanz ausfällt und auf dem Standby-Server die Instanz noch nicht von MOUNTED auf OPEN umgestellt wurde.

Weisen Sie die Berechtigung dem Benutzer zu, welcher die Daten von den Instanzen abholen darf. Wichtig: Wie das funktioniert, kann von dem folgenden Beispiel abweichen. Die Rolle wird hier dem Benutzer zugewiesen, wie er im Beispiel der Ersteinrichtung angelegt wurde:

Damit die Daten im Fehlerfall vom Agentenplugin auf dem Standby-Server abgefragt werden können, legen Sie den Benutzer auf der primären Instanz an und kopieren Sie die Passwortdatei danach auf den Standby-Server. In der Konfigurationsdatei des Plugins setzen Sie abschließend die Rolle des Benutzers auf SYSDBA:

Beachten Sie, dass die Angabe eines Hosts, Ports oder des TNS-Alias optional ist und weggelassen werden kann. Zusätzlich muss natürlich das Agentenplugin sowohl auf dem Host der primären Instanz als auch auf den Hosts der Standby-Instanzen installiert sein.

Auf der Seite von Checkmk ist es notwendig, dass Sie — egal, ob Sie ADG oder DG nutzen — die Services anpassen und einem Cluster-Host zuweisen. Die entsprechenden Check-Plugins wurden bereits soweit vorbereitet, dass Sie auch als Cluster-Services konfiguriert werden können. Legen Sie also in Checkmk einen Cluster-Host an und fügen Sie diesem als Knoten die einzelnen Oracle-Hosts zu, auf denen die primäre und die Standby-Instanzen laufen. Danach weisen Sie diesem Cluster-Host die folgenden Services zu:

Sie brauchen sich sich nun nicht mehr darum zu kümmern, von welcher Instanz die Daten kommen und haben auch im Falle eines Schwenks der primären Instanz eine nahtlose Überwachung der genannten Services sichergestellt.

Auch bei einem RAC ist es sinnvoll, Cluster-Services einzurichten. Zusätzlich zu den Services, die Sie bei einem (Active) Data Guard dem Cluster-Host zuordnen, weisen Sie auch die folgenden Services zu, um im Falle eines Schwenks eine nahtlose Überwachung sicherzustellen:

Die einfachste Weise so ein SQL anzubinden, ist die Nutzung des Check-Plugins Oracle Database: Custom SQLs. Erstellen Sie dafür zunächst die Datei MyCustomSQL.sql in dem Konfigurationsverzeichnis des Agenten auf dem Hosts, auf dem das SQL ausgeführt werden soll.

Nachfolgend ein Dummy, welcher die Syntax veranschaulicht:

Das Beispiel zeigt zum einen, dass Sie in einer solchen Datei beliebig viele Anweisungen definieren können. Zum anderen ist die Syntax dem eines lokalen Checks sehr ähnlich, vor allem mit Blick auf die Metriken. Im Detail ist diese Syntax hier wesentlich mächtiger, da Sie mehrzeilige Ausgaben erzeugen können und diese dann auf dem Checkmk-Server als ein Service verarbeitet werden. Prinzipiell sind alle Zeilen optional und müssen nicht befüllt werden.

Die möglichen Schlüsselwörter sind im Einzelnen:

Nachdem Sie nun Ihr erstes, sehr einfaches SQL definiert haben, machen Sie es dem Agentenplugin mk_oracle bekannt. Das erfolgt über die bekannte Konfigurationsdatei, die Sie entsprechend erweitern:

Mit der ersten Option (SQLS_SECTIONS) bestimmen Sie, welche individuellen Sektionen Sie ausführen lassen möchten. Beachten Sie, dass mit Sektion hier ein Teil der Ausgabe des Agentenplugins gemeint ist — und nicht ein Teil einer Datenbankinstanz. Im Beispiel haben wir nur eine Sektion (mycustomsection1) angegeben und diese dann direkt danach näher beschrieben. Jede Sektion ist also eigentlich eine kleine Funktion, die vom Agentenplugin aufgerufen wird.

In dieser Funktion können Sie dann weitere Details bestimmen und festlegen, für welche Instanzen (SQLS_SIDS) diese Sektion gilt. Außerdem bestimmen Sie zusätzlich, wo sich die Datei mit den SQL-Anweisungen befindet (SQLS_DIR) und wie diese Datei heißt (SQLS_SQL).

Diese einfache Konfiguration reicht bereits aus, um das Ergebnis in Checkmk sehen zu können. Führen Sie dafür eine Service-Erkennung durch und aktivieren Sie den neuen Service. Danach sehen Sie ihn bei den anderen Services in der Übersicht des Hosts:

Sollten Sie Problem mit der Verbindung zu einer oder mehreren Instanzen auf einem Oracle-Server haben, können Sie als Erstes grundlegende Parameter prüfen lassen. Wenn Sie das Agentenplugin mit der Option -t starten, gibt es die Details zu einer Verbindung aus. Beachten Sie, dass dem Agentenplugin zuvor der Pfad zu seiner Konfigurationsdatei bekannt gemacht werden muss, da es sich darauf verlässt. In der Ausgabe wurden die Dummy-Sektionen zugunsten der Lesbarkeit weggelassen. Im Folgenden also das Beispiel auf einem Linux-Server:

Da man diesen Aufruf eher im Fehlerfall machen wird, werden Sie dann auch weitere Informationen erhalten: Sowohl den Connection String, welcher für die Verbindung benutzt wurde, als auch die ersten 100 Zeichen der Fehlermeldung, die bei dem Verbindungsversuch zurückgegeben wurden. Mit Hilfe dieser Informationen können Sie bereits schnell einfache Konfigurationsprobleme identifizieren und dann auch entsprechend beheben.

Das Agentenplugin akzeptiert unter Windows keine Parameter. Um hier also die Verbindung zu testen, limitieren Sie temporär die abzurufenden Sektionen auf instance und aktivieren Sie die Option DEBUG:

Führen Sie danach das Agentenplugin manuell aus. Auch hier werden Sie Informationen darüber bekommen, wie das Plugin versucht, auf die Instanzen zuzugreifen. Eine Ausgabe kann dann z.B. so aussehen:

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. Auch hier benötigen Sie den Pfad zu der Konfigurationsdatei und zusätzlich auch den Pfad zu den zwischengespeicherten Daten des Plugins. Auch im folgenden Beispiel wurde die Ausgabe der Sektionen übersprungen, um die Lesbarkeit zu erhöhen:

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

Das Logging unter Windows funktioniert ähnlich wie der oben beschriebene Verbindungstest. Ist die Verbindung selbst stabil, können Sie in der Konfigurationsdatei die echten Sektionen wieder hinzufügen und bekommen dann entsprechend eine komplette Logging-Ausgabe.

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. Sie können das Debugging mit der Option -d aufrufen. Vergessen Sie auch hier nicht die notwendige Umgebungsvariable:

Wichtig: In dieser Ausgabe werden keine sensiblen Daten wie Passwörter maskiert. Es ist also alles in Klartext lesbar.

Unter Windows steht Ihnen eine ähnliche Funktionalität zur Verfügung. Da Sie dem Agentenplugin keine Argumente übergeben können, müssen Sie das Tracing allerdings manuell anschalten: