Checkmk
to checkmk.com

1. Einleitung

Checkmk bietet Ihnen umfangreiche Möglichkeiten Oracle-Datenbanken zu überwachen. So können Sie mit dem Agentenplugin nicht nur Tablespaces oder die aktiven Sitzungen einer Datenbank abrufen, sondern zusätzlich noch viele andere Metriken. Eine vollständige Liste der Überwachungsmöglichkeiten mit unseren Check-Plugins können Sie im Katalog der Check-Plugins nachlesen. Wir erweitern diese Plugins regelmäßig, so dass sich ein Blick in den Katalog immer wieder lohnt. Unter anderem kann Checkmk die folgenden Werte überwachen:

Um die Datenbanken überwachen zu können, brauchen Sie lediglich das Agentenplugin zusätzlich zu dem Agenten auf dem Datenbankserver. Unterstützt werden dafür zur Zeit die Betriebssysteme Linux, Solaris, AIX und Windows. Das Agentenplugin für Linux, Solaris, AIX heißt mk_oracle und für Windows mk_oracle.ps1. Zusätzliche Software wird weder auf dem Checkmk-Server noch auf dem Datenbankserver für eine Überwachung benötigt.

Viele Schritte, um die Überwachung einzurichten, sind zwischen Linux und Windows gleich. Aus diesem Grund werden zunächst die allgemeinen Schritte beschrieben, dann die spezifischen für die jeweilige Betriebssystemgruppe und schließlich die Agentenbäckerei der kommerziellen Editionen.

2. Ersteinrichtung

Die in diesem und den folgenden Kapiteln vorgestellten Konfigurationsdateien mit Beispielinhalten finden Sie auf dem Checkmk-Server — entweder über die Kommandozeile oder über die Checkmk-Weboberfläche. In Raw Edition wählen Sie Setup > Agents und in den kommerziellen Editionen Setup > Agents > Windows, Linux, Solaris, AIX > Related. In allen Editionen finden Sie dort Menüeinträge für die unterschiedlichen Betriebssysteme. Die Konfigurationsdateien finden Sie im Kasten Example Configurations.

2.1. Datenbankbenutzer erstellen

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:

root@linux# su - oracle
oracle@linux$ export ORACLE_SID=MYINST1

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:

sqlplus> create user checkmk identified by myPassword;
sqlplus> grant select_catalog_role to checkmk;
sqlplus> grant create session to checkmk;
sqlplus> connect checkmk/myPassword
sqlplus> exit

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

Multi-Tenant-Datenbanken

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:

sqlplus> create user c##checkmk identified by myPassword;
sqlplus> alter user c##checkmk set container_data=all container=current;
sqlplus> grant select_catalog_role to c##checkmk container=all;
sqlplus> grant create session to c##checkmk container=all;
sqlplus> exit

2.2. Konfiguration erstellen

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. Legen Sie also nun auf dem Oracle-Host die Konfigurationsdatei mk_oracle.cfg für Linux, AIX, Solaris oder mk_oracle_cfg.ps1 für Windows an. In dem folgenden Beispiel sehen Sie die Datei für die Unix-artigen Systeme:

/etc/check_mk/mk_oracle.cfg
# Syntax:
# DBUSER='USERNAME:PASSWORD'
DBUSER='checkmk:myPassword'

Für Windows sieht das sehr ähnlich aus. Hier setzen Sie die Variable in einem PowerShell-Skript:

C:\ProgramData\checkmk\agent\config\mk_oracle_cfg.ps1
# Syntax:
# $DBUSER = @("USERNAME","PASSWORD")
$DBUSER = @("checkmk","myPassword")

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.

2.3. Oracle-Wallet nutzen

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, so dass sie benutzt werden können, aber keine Login-Daten explizit bekannt gemacht werden müssen. Checkmk kann dieses Wallet nutzen, so dass die Zugangsdaten prinzipiell nur dem Datenbankadministrator (DBA) bekannt sein müssen. Dazu legen Sie — oder der DBA — ein Wallet auf dem entsprechenden Server an:

root@linux# mkstore -wrl /etc/check_mk/oracle_wallet -create

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:

root@linux# mkstore -wrl /etc/check_mk/oracle_wallet -createCredential MYINST1 checkmk myPassword

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, so dass 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, so dass 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:

/etc/check_mk/sqlnet.ora
LOG_DIRECTORY_CLIENT = /var/log/check_mk/oracle_client
DIAG_ADR_ENABLED = OFF

SQLNET.WALLET_OVERRIDE = TRUE
WALLET_LOCATION =
 (SOURCE=
   (METHOD = FILE)
   (METHOD_DATA = (DIRECTORY=/etc/check_mk/oracle_wallet))
 )

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:

/etc/check_mk/tnsnames.ora
MYINST1
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = 127.0.0.1)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = MYINST1_ALIAS)
    )
  )

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:

/etc/check_mk/mk_oracle.cfg
DBUSER='/:'

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 Kommandos ändern die Gruppe zu oinstall:

root@linux# chgrp oinstall /etc/check_mk/sqlnet.ora /etc/check_mk/tnsnames.ora
root@linux# chgrp -R oinstall /etc/check_mk/oracle_wallet

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

root@linux# chmod g+x /etc/check_mk/oracle_wallet
root@linux# chmod -R g+r /etc/check_mk/oracle_wallet

Anschließend sollten die Berechtigungen etwa wie folgt aussehen:

root@linux# tree -ugpR /etc/check_mk
[drwxr-xr-x root     root    ]  /etc/check_mk
├── [drwxr-x--- root   oinstall ]  oracle_wallet
│   └── [-rw-r----- root   oinstall ]  cwallet.sso
│   └── [-rw-r----- root   oinstall ]  cwallet.sso.lck
│   └── [-rw-r----- root   oinstall ]  ewallet.p12
│   └── [-rw-r----- root   oinstall ]  ewallet.p12.lck
├── [-rw-r--r-- root   oinstall ]  sqlnet.ora
├── [-rw-r--r-- root   oinstall ]  tnsnames.ora

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

3. Einrichtung für Linux, Solaris, AIX

3.1. Plugin- und Konfigurationspfade

Unter Unix-artigen Systemen verwendet Checkmk ein einheitliches Agentenplugin. Das reduziert zum einen den Aufwand der Pflege, da SQL-Abfragen nicht dupliziert werden müssen, und sorgt zum anderen dafür, dass Sie nur ein einziges Agentenplugin zu beachten haben. Auf allen unterstützten Systemen sind die Pfade für die Agenten gleich oder sehr ähnlich. Konkret benötigen Sie die folgenden Verzeichnisse:

Betriebssystem Plugin-Pfad Konfigurationspfad

Linux, Solaris, AIX

/usr/lib/check_mk_agent/plugins/

/etc/check_mk/

Linux mit systemd

/usr/lib/check_mk_agent/plugins/<Zahl>

/etc/check_mk/

AIX

/usr/check_mk/lib/plugins/

/usr/check_mk/conf/

3.2. Agentenplugin installieren

Nachdem Sie bei der Ersteinrichtung einen Benutzer angelegt und diesen in der Konfigurationsdatei hinterlegt haben, installieren Sie nun noch das Agentenplugin. Kopieren Sie die Datei mk_oracle vom Checkmk-Server aus dem Verzeichnis ~/share/check_mk/agents/plugins/ auf den Oracle-Host in das oben beschriebene Plugin-Verzeichnis.

Important

Das Agentenplugin für Unix-artige Systeme mk_oracle verträgt sich nicht gut mit systemd (siehe Werk #13732). Auf Systemen mit systemd müssen Sie das Agentenplugin daher asynchron ausführen lassen. Das heißt, Sie installieren das Agentenplugin nicht unter /usr/lib/check_mk_agent/plugins/ direkt, sondern in einem Unterordner /usr/lib/check_mk_agent/plugins/<Zahl>/. <Zahl> meint dabei das Ausführungsintervall in Sekunden. Wir empfehlen die minütliche Ausführung, also /usr/lib/check_mk_agent/plugins/60/. Bei der Einrichtung über die Agentenbäckerei erledigen Sie das freilich über die Option Host uses xinetd or systemd in der Oracle-Regel, bei der standardmäßig xinetd vorgegeben ist.

Achten Sie darauf, dass das Agentenplugin ausführbar ist und korrigieren Sie das gegebenenfalls:

root@linux# cd /usr/lib/check_mk_agent/plugins/
root@linux# ls -lA
-rw-r--r-- 1 root root 120808 Jan 25 11:29 mk_oracle
root@linux# chmod +x mk_oracle
root@linux# ls -lA
-rwxr-xr-x 1 root root 120808 Jan 25 11:29 mk_oracle

3.3. Erweiterte Optionen

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.

Erweiterte Benutzerkonfiguration

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:

Parameter Beschreibung

DBUSER

Der Standard, wenn keine individuellen Zugangsdaten für die Datenbankinstanz definiert sind.

DBUSER_MYINST1

Zugangsdaten für eine ganz bestimmte Datenbankinstanz, in diesem Fall für die Instanz MYINST1. Die Zugangsdaten werden nur für diese Instanz benutzt.

ASMUSER

Spezielle Zugangsdaten für das Automatic Storage Management (ASM).
Wichtig: Für ein ASM kann immer nur ein Login angegeben werden.

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:

/etc/check_mk/mk_oracle.cfg
# Syntax
# DBUSER='USERNAME:PASSWORD:ROLE:HOST:PORT:TNSALIAS'
DBUSER='checkmk:myPassword'

DBUSER_MYINST1='cmk_specific1:myPassword1:SYSDBA:localhost:1521'
DBUSER_MYINST2='cmk_specific2:myPassword2::localhost::INST2'

ASMUSER='cmk_asm:myASMPassword:SYSASM'

Ein paar Erläuterungen zu dem Beispiel:

  • Sie können beliebig viele individuelle Zugangsdaten definieren. Diese werden immer gegenüber dem Standard bevorzugt.

  • Jede Option wird von den anderen durch ein : (Doppelpunkt) getrennt.

  • Wird ein optionales Feld mittendrin ausgelassen, muss der Doppelpunkt geschrieben werden, wie beim Eintrag DBUSER_MYINST2, bei dem keine Rolle und kein Port angegeben wurde.

  • Werden ab einem bestimmten Punkt keine optionalen Felder mehr gebraucht, können Sie die Doppelpunkte weglassen, wie beim Eintrag ASMUSER, bei dem weder Host, Port noch TNS-Alias angegeben wurde.

Instanzen ein- oder ausschließen

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:

Parameter Beschreibung

ONLY_SIDS

Hiermit können Sie bestimmen, welche Instanzen überwacht werden sollen. Eine Instanz wird dabei durch ihren System Identifier (SID) benannt. Es handelt sich hierbei um eine positive Liste, bei der alle Instanzen ignoriert werden, die nicht explizit gelistet sind. Dieser Parameter eignet sich also sehr gut, wenn die Menge der zu überwachenden Instanzen kleiner ist, als die Anzahl derer, die ignoriert werden sollen.

SKIP_SIDS

Im Gegensatz zu ONLY_SIDS handelt es sich hier um eine negative Liste, bei der alle Instanzen außer der hier explizit gelisteten überwacht werden. Dieser Parameter eignet sich daher sehr gut, wenn die Anzahl der zu ignorierenden Instanzen kleiner ist, als diejenige, die überwacht werden soll.

EXCLUDE_<SID>

Mit diesem Parameter können Sie eine Instanz teilweise ausschließen, indem Sie bestimmte Sektionen der Instanz von der Überwachung ausschließen. Auf diese Weise definieren Sie eine Negativliste der Sektionen einer Instanz. Sie können mit dem Wert ALL auch alle Sektionen ausschließen und erreichen damit dasselbe, als würden Sie sie die Instanz zu SKIP_SIDS hinzufügen.
Wichtig: Für ASM-SIDs können Sie dieses Konzept nicht verwenden, aber Sie können stattdessen SKIP_SIDS="+ASM1 …​" verwenden.

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:

/etc/check_mk/mk_oracle.cfg
ONLY_SIDS='INST1 INST2 INST5'
SKIP_SIDS='INST7 INST3 INST2'
EXCLUDE_INST1='ALL'
EXCLUDE_INST2='tablespaces rman'

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.

Zu holende Daten 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:

Parameter Beschreibung

SYNC_SECTIONS

Sektionen, die synchron — das heißt bei jedem Lauf des Agenten — abgefragt werden sollen. Da das Abfrageintervall im Standard bei 60 Sekunden liegt, müssen die benutzten SQL-Abfragen entsprechend schnell durchlaufen. Wird die Variable nicht angegeben, werden alle Sektionen abgefragt.

ASYNC_SECTIONS

Sektionen, die asynchron — das heißt nur alle x Minuten — abgefragt werden sollen. Wie lange die Daten gültig sind, bestimmt die Variable CACHE_MAXAGE weiter unten in der Tabelle.

SYNC_ASM_SECTIONS

Hier greift der gleiche Mechanismus für Sektionen der ASM, der bei der Variablen SYNC_SECTIONS allgemein beschrieben ist.

ASYNC_ASM_SECTIONS

Hier greift der gleiche Mechanismus für Sektionen der ASM, der bei der Variablen ASYNC_SECTIONS allgemein beschrieben ist.

CACHE_MAXAGE

Mit dieser Variable bestimmen Sie, wie lange asynchron abgerufene Daten valide sind. Wird die Variable nicht angegeben, wird ein Standard von 600 Sekunden (10 Minuten) benutzt. Achten Sie darauf, den Zeitraum nicht kürzer zu wählen, als das Intervall, mit dem der Checkmk-Agent die Daten anliefert (standardmäßig 60 Sekunden). Andernfalls kann es passieren, dass die Daten als veraltet betrachtet und vom Agenten nicht mitgeliefert werden.

MAX_TASKS

Anzahl der SIDs, die parallel verarbeitet werden. Der Standardwert ist 1.

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:

/etc/check_mk/mk_oracle.cfg
# DEFAULTS:
# SYNC_SECTIONS="instance sessions logswitches undostat recovery_area processes recovery_status longactivesessions dataguard_stats performance locks"
# ASYNC_SECTIONS="tablespaces rman jobs ts_quotas resumable"
# SYNC_ASM_SECTIONS="instance processes"
# ASYNC_ASM_SECTIONS="asm_diskgroup"
# CACHE_MAXAGE=600

SYNC_ASM_SECTIONS='instance'
ASYNC_SECTIONS='tablespaces jobs rman resumable'

CACHE_MAXAGE=300

EXCLUDE_INST1='undostat locks'
EXCLUDE_INST2='jobs'

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.

Important

Wenn Sie in der Konfigurationsdatei bestimmen, welche Sektionen auf welche Weise abgeholt werden sollen — Sie können ja auch eine asynchrone Sektion zu einer synchronen machen — müssen Sie alle Sektionen angeben, welche in dem jeweiligen Bereich ausgeführt werden sollen.

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

/etc/check_mk/mk_oracle.cfg
# Just exclude 'locks' from sync sections:
SYNC_SECTIONS='instance sessions logswitches undostat recovery_area processes recovery_status longactivesessions dataguard_stats performance'

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

TNS-Alias und TNS_ADMIN konfigurieren

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:

/etc/check_mk/mk_oracle.cfg
export TNS_ADMIN=/opt/oracle/product/19c/dbhome_1/network/admin/

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

Zugriffsrechte bei der Ausführung

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.

Tip

In welcher Patch-Version von Checkmk diese Änderung durchgeführt wurde, können Sie in den Werks #15327 und #15328 nachlesen.

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

3.4. Entfernte Datenbanken überwachen

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:

  • Die Linux AIO access library ist installiert. Unter RHEL und Derivaten heißt das Paket libaio.

  • Der Oracle Instant Client ist installiert.

  • Das Programm sqlplus ist in der Installation schon vorhanden oder wurde ggf. als Erweiterungspaket zu dem Client installiert.

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:

/etc/check_mk/mk_oracle.cfg
# Syntax:
# REMOTE_INSTANCE_[ID]='USER:PASSWORD:ROLE:HOST:PORT:PIGGYBACKHOST:SID:VERSION:TNSALIAS'

REMOTE_INSTANCE_1='check_mk:mypassword::myRemoteHost:1521:myOracleHost:MYINST3:11.2'
REMOTE_INSTANCE_myinst1='/:::myRemoteHost:1521::MYINST1:11.2:INST1'

REMOTE_ORACLE_HOME='/usr/lib/oracle/11.2/client64'

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:

  • Da Sie die entfernten Instanzen in der Konfigurationsdatei explizit eingetragen haben, können Sie diese Instanzen nicht per SKIP_SIDS ausschließen und brauchen sie im Gegenzug auch nicht mit ONLY_SIDS einzuschließen.

  • Instanzen mit gleichem Namen (SID) dürfen nicht demselben Host zugewiesen werden. Das ist vor allem dann relevant, wenn Sie Instanzen von mehreren entfernten Hosts und/oder dem lokalen Host abrufen und dort identische Namen verwendet werden.

4. Einrichtung für Windows

4.1. Plugin- und Konfigurationspfade

Unter Windows wird PowerShell als Skriptsprache benutzt, um Oracle-Datenbanken zu überwachen. Die Funktionalität ist an das Agentenplugin unter Unix-artigen Systemen angelehnt, enthält aber nur einen Teil davon. Um das Agentenplugin unter Windows nutzen zu können, benötigen Sie die folgenden Verzeichnisse:

Betriebssystem Plugin-Pfad Konfigurationspfad

Windows

C:\ProgramData\checkmk\agent\plugins

C:\ProgramData\checkmk\agent\config

4.2. Agentenplugin installieren

Nachdem Sie bei der Ersteinrichtung einen Benutzer angelegt und diesen in der Konfigurationsdatei hinterlegt haben, installieren Sie nun noch das Agentenplugin. Die Agentenplugins für Windows werden bei der Installation des Checkmk-Agenten für Windows auf dem Host abgelegt. Kopieren Sie auf dem Oracle-Host die Datei mk_oracle.ps1 aus dem Verzeichnis C:\Program Files (x86)\checkmk\service\plugins\ in das oben beschriebene Plugin-Verzeichnis. Alternativ dazu können Sie in der Konfigurationsdatei des Checkmk-Agenten auf die Datei im Installationspfad verweisen.

4.3. Besonderheiten unter Windows

Windows verhindert normalerweise die Ausführung von PowerShell-Skripten, wenn diese nicht signiert sind. Sie können dieses Problem nun sehr einfach umgehen, indem Sie die Richtlinien zur Ausführung von PowerShell-Skripten für den Benutzer anpassen, welcher den Checkmk-Agenten ausführt:

PS C:\ProgramData\checkmk\agent\> Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope LocalMachine
PS C:\ProgramData\checkmk\agent\> Get-ExecutionPolicy -Scope LocalMachine
Bypass

Diese Option ist praktisch, wenn man kurz ein Skript oder die generelle Funktionalität des Checkmk-Agenten testen möchte. Um die Sicherheit Ihres Systems nicht zu gefährden, setzen Sie nach dem Test die Einstellung auf produktiven Servern wieder zurück:

PS C:\Program\checkmk\agent\> Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine
PS C:\Program\checkmk\agent\> Get-ExecutionPolicy -Scope LocalMachine
RemoteSigned

Verständlicherweise haben Sie wahrscheinlich keine Lust, alle 60 Sekunden die Richtlinien umzustellen. Setzen Sie daher eine permanente Ausnahme nur für die relevanten Skripte. Dabei muss auch die Konfigurationsdatei des Agentenplugins zu den Ausnahmen hinzugefügt werden. Die Ausgabe aus dem Beispiel wurde zu Gunsten der Lesbarkeit komplett weggelassen:

PS C:\ProgramData\checkmk\agent\> Unblock-File -Path .\plugins\mk_oracle.ps1
PS C:\ProgramData\checkmk\agent\> Unblock-File -Path .\config\mk_oracle_cfg.ps1

4.4. Erweiterte Optionen

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. Optionen, die Ihnen auch unter Windows zur Verfügung stehen, finden Sie in den nachfolgenden Abschnitten.

Erweiterte Benutzerkonfiguration

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:

Parameter Beschreibung

DBUSER

Der Standard, wenn keine individuellen Zugangsdaten für die Datenbankinstanz definiert sind.

DBUSER_MYINST1

Zugangsdaten für eine ganz bestimmte Datenbankinstanz, in diesem Fall für die Instanz MYINST1. Die Zugangsdaten werden nur für diese Instanz benutzt.

ASMUSER

Spezielle Zugangsdaten für das Automatic Storage Management (ASM).
Wichtig: Für ein ASM kann immer nur ein Login angegeben werden.

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:

C:\ProgramData\checkmk\agent\config\mk_oracle_cfg.ps1
# Syntax
# DBUSER = @("USERNAME", "PASSWORD", "ROLE", "HOST", "PORT")
# Default
# DBUSER = @("", "", "", "localhost", "1521")
$DBUSER = @("checkmk", "myPassword", "SYSDBA", "localhost", "1521")

@DBUSER_MYINST1 = @("cmk_specific1", "myPassword1", "", "10.0.0.73")
@DBUSER_MYINST2 = @("cmk_specific2", "myPassword2", "SYSDBA", "localhost", "1531")

@ASMUSER = @("cmk_asm", "myASMPassword", "SYSASM")

Ein paar Erläuterungen zu dem Beispiel:

  • Sie können beliebig viele individuelle Zugangsdaten definieren. Diese werden immer gegenüber dem Standard bevorzugt.

  • Jede Option wird in einer Liste definiert. Die Reihenfolge der Einträge ist nicht beliebig und darf daher nicht vertauscht werden.

  • Soll ein optionales Feld nicht verändert werden, aber ein danach folgendes, so müssen beide korrekt angegeben werden, wie beim Eintrag DBUSER_MYINST2, bei dem der HOST weiterhin auf localhost gesetzt wird, obwohl nur der PORT verändert werden soll.

  • Werden ab einem bestimmten Punkt keine optionalen Felder mehr gebraucht, können sie weggelassen werden, wie beim Eintrag ASMUSER, bei dem nur die Rolle des Benutzers angegeben wurde.

  • Soll dem Benutzer keine spezielle Rolle zugewiesen, aber HOST oder PORT angepasst werden, tragen Sie an der Stelle lediglich zwei Anführungszeichen ("") ein.

Instanzen ein- oder ausschließen

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:

Parameter Beschreibung

ONLY_SIDS

Hiermit können Sie bestimmen, welche Instanzen überwacht werden sollen. Eine Instanz wird dabei durch ihren System Identifier (SID) benannt. Es handelt sich hierbei um eine positive Liste, bei der alle Instanzen ignoriert werden, die nicht explizit gelistet sind. Dieser Parameter eignet sich also sehr gut, wenn die Menge der zu überwachenden Instanzen kleiner ist, als die Anzahl derer, die ignoriert werden sollen.

EXCLUDE_<SID>

Da Ihnen unter Windows der Parameter SKIP_SIDS nicht zur Verfügung steht, können Sie nur mit EXCLUDE_<SID> Instanzen ausschließen und dadurch eine negative Liste definieren. Sie machen das, in dem Sie den Wert der Variable auf ALL setzen. Zusätzlich können Sie mit diesem Parameter eine Instanz teilweise ausschließen, indem Sie bestimmte Sektionen der Instanz von der Überwachung ausschließen. Auf diese Weise definieren Sie eine Negativliste der Sektionen einer Instanz.
Wichtig: Eine ASM (+ASM) kann mit dieser Option nicht komplett ausgeschlossen werden.

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:

C:\ProgramData\checkmk\agent\config\mk_oracle_cfg.ps1
$ONLY_SIDS = @("MYINST1", "MYINST3")
$EXCLUDE_INST1 = "tablespaces rman"
$EXCLUDE_INST3 = "ALL"

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.

Zu holende Daten bestimmen

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

C:\ProgramData\checkmk\agent\config\mk_oracle_cfg.ps1
# DEFAULTS:
# $SYNC_SECTIONS = @("instance", "sessions", "logswitches", "undostat", "recovery_area", "processes", "recovery_status", "longactivesessions", "dataguard_stats", "performance", "locks")
# $ASYNC_SECTIONS = @("tablespaces", "rman", "jobs", "ts_quotas", "resumable")
# $SYNC_ASM_SECTIONS = @("instance", "processes")
# $ASYNC_ASM_SECTIONS = @("asm_diskgroup")
# $CACHE_MAXAGE = 600

$SYNC_ASM_SECTIONS = @("instance")
$ASYNC_SECTIONS = @("tablespaces", "jobs", "rman", "resumable")

$CACHE_MAXAGE = 300

$EXCLUDE_INST1 = "undostat locks"
$EXCLUDE_INST2 = "jobs'
Important

Wenn Sie in der Konfigurationsdatei bestimmen, welche Sektionen auf welche Weise abgeholt werden sollen — Sie können ja auch eine asynchrone Sektion zu einer synchronen machen — müssen Sie alle Sektionen angeben, welche in dem jeweiligen Bereich ausgeführt werden sollen.

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

C:\ProgramData\checkmk\agent\config\mk_oracle_cfg.ps1
# Just exclude 'locks' from sync sections:
$SYNC_SECTIONS = @("instance", "sessions", "logswitches", "undostat", "recovery_area", "processes", "recovery_status", "longactivesessions", "dataguard_stats", "performance")

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

Zugriffsrechte bei der Ausführung

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 LocalSystem-Konto 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.

Tip

In welcher Patch-Version von Checkmk diese Änderung durchgeführt wurde, können Sie im Werk #15843 nachlesen.

Ä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:

C:\ProgramData\checkmk\agent\config\mk_oracle_cfg.ps1
# Oracle plugin will allow users and groups in the list to have write access to the Oracle binaries
$WINDOWS_SAFE_ENTRIES=@("NT AUTHORITY\Authenticated Users", "<Domain>\<User>")

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.

Important

Wenn Sie die Prüfung der Zugriffsrechte abschalten, wird das Agentenplugin nicht mehr sicher ausgeführt.

C:\ProgramData\checkmk\agent\config\mk_oracle_cfg.ps1
# Oracle plugin will not check if the used binaries are write-protected for non-admin users
$SKIP_ORACLE_SECURITY_CHECK=1

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:

C:\ProgramData\checkmk\agent\check_mk.user.yml
plugins:
    enabled: yes
    execution:
        - pattern: $CUSTOM_PLUGINS_PATH$\mk_oracle.ps1
          async: yes
          group: Users
          run: true

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

4.5. Entfernte Datenbanken überwachen

Die Überwachung entfernter Datenbanken ist derzeit nicht mit dem Agentenplugin für Windows möglich. Wenn Sie entfernte Datenbanken überwachen wollen, benötigen Sie daher einen Host mit einem kompatiblen Unix-artigen Betriebssystem.

5. Einrichtung mit der Agentenbäckerei

CEE Die Einrichtung wird in den kommerziellen Editionen mit der Agentenbäckerei stark vereinfacht, da Syntaxfehler in den Konfigurationsdateien vermieden und Anpassungen an sich verändernde Umgebungen einfacher umgesetzt werden können. Der wesentliche Unterschied zu einer manuellen Konfiguration ist, dass Sie nur noch dann auf dem Oracle-Host auf der Kommandozeile arbeiten müssen, wenn Sie spezielle Oracle-spezifische Konfigurationen vornehmen wollen. Die Einrichtung mit der Agentenbäckerei können Sie für Linux, Solaris, AIX und Windows durchführen.

Trotzdem können Sie nicht alle Funktionen des Agentenplugins über die Agentenbäckerei konfigurieren, zum Beispiel wenn es Funktionen sind, welche einen größeren Eingriff benötigen und ein fundiertes Fachwissen voraussetzen. Entsprechend sind die benutzerdefinierten SQL-Abfragen nicht in der Agentenbäckerei konfigurierbar.

Über Setup > Agents > Windows, Linux, Solaris, AIX und das Menü Agents > Agent rules finden Sie die Seite mit dem Regelsatz Oracle databases (Linux, Solaris, AIX, Windows). Erstellen Sie mit Add rule eine neue Regel. Hier finden Sie alle Optionen, die Ihnen für die Konfiguration des Agentenplugins zur Verfügung stehen:

Regel zur Konfiguration von Oracle in der Agentenbäckerei.

Viele Optionen werden ihnen aus der manuellen Einrichtung bekannt vorkommen. Wie dort beschrieben, gibt es Optionen, die nicht für alle Betriebssysteme verfügbar sind. Der Titel dieser Optionen zeigt, für welche Betriebssysteme sie genutzt werden können.

5.1. Benutzer konfigurieren

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

Einfachste Regel zur Konfiguration von Oracle in der Agentenbäckerei.

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 für Linux, Solaris, AIX und Windows beschrieben ist.

5.2. Erweiterte Optionen

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:

Option Beschreibung

Host uses xinetd or systemd (Linux/AIX/Solaris only)

Diese Option muss für Unix-artige Systeme mit xinetd/systemd aktiviert werden. Bei systemd ist die asynchrone Ausführung des Agentenplugins obligatorisch — im von Ihnen festgelegten Intervall. Mehr dazu finden Sie bei der Installation des Agentenplugins.

Instances to monitor

Diese Option fasst mehrere Optionen der Konfigurationsdatei zusammen, mit denen Sie Instanzen für Linux, Solaris, AIX oder Windows ein- oder ausschließen können.

Add pre or postfix to TNSALIASes (Linux/AIX/Solaris only)

Mit dieser Option können Sie den TNS-Alias entweder global oder für eine spezifische Instanz erweitern.

Sections - data to collect

Alle verfügbaren Sektionen sind unter dieser Option gelistet und können individuell auf globaler Ebene konfiguriert werden. Sie entsprechen daher den Variablen SYNC_SECTIONS und ASYNC_SECTIONS sowie für ASM deren Gegenstücken SYNC_ASM_SECTIONS und ASYNC_ASM_SECTIONS. Mehr dazu im Abschnitt über die zu holenden Daten für Linux, Solaris, AIX oder Windows.

Exclude some sections on certain instances

Wenn Sie mit EXCLUDE_<SID> nicht die gesamte Instanz, sondern nur ein paar Sektionen ausschließen wollen, können Sie dies mit dieser Option festlegen, so wie für Linux, Solaris, AIX oder Windows beschrieben.

Cache age for background checks

Legen Sie hier fest, wie lange asynchrone Sektionen gültig sein sollen. Der Standardwert liegt bei 600 Sekunden (10 Minuten).

Sqlnet Send timeout

Diese Option wird der Datei sqlnet.ora hinzugefügt und setzt ein Timeout, welches für alle Instanzen gilt.

Remote instances (Linux/AIX/Solaris only)

Entfernte Instanzen konfigurieren Sie mit dieser Option. Sie enthält alle Elemente der Konfiguration, die Sie bereits kennen. Für die Bestimmung der ID der Variablen haben Sie über die Unique ID die Wahl aus verschiedenen Möglichkeiten. Sie müssen nur darauf achten, dass die ID innerhalb der Konfiguration eindeutig ist.

ORACLE_HOME to use for remote access (Linux/AIX/Solaris only)

Hier können Sie bestimmen, wo das Agentenplugin das Programm sqlplus findet. Sie müssen hier einen Wert eintragen, wenn Sie eine entfernte Instanz überwachen wollen, aber sqlplus nicht über die Umgebungsvariablen gefunden werden kann.

TNS_ADMIN to use for sqlnet.ora and tnsnames.ora (Linux/AIX/Solaris only)

Falls die beiden Dateien in einem anderen Verzeichnis als /etc/check_mk/ liegen, können Sie mit dieser Option den Pfadnamen über die Umgebungsvariable TNS_ADMIN festlegen.

sqlnet.ora permission group (Linux/AIX/Solaris only)

Tragen Sie hier die Linux-Gruppe des nicht privilegierten Benutzers ein, der Eigentümer der Oracle-Binärprogramme ist, damit dieser Benutzer die Datei sqlnet.ora lesen kann, die von der Agentenbäckerei erstellt wird. Bei einer Standard-Oracle-Installation kann oinstall als Gruppe verwendet werden.
Weitere Informationen finden Sie im Abschnitt Zugriffsrechte bei der Ausführung für Linux. Dort werden auch andere Dateien und Verzeichnisse genannt, z.B. tnsnames.ora, die nicht von der Agentenbäckerei erstellt werden. Für diese manuell erstellten Dateien und Verzeichnisse müssen Sie auch die notwendigen Berechtigungen manuell setzen.

Oracle binaries permissions check (Windows only)

Hier können Sie die Prüfung der Zugriffsrechte für die Oracle-Binärprogramme konfigurieren, indem Sie einzelnen, nicht-administrativen Benutzern und Gruppen die Ausführung der Programme erlauben. Die Prüfung ausschalten sollten Sie nur, wenn Sie wissen, was Sie tun. Mehr zum Thema finden Sie im Abschnitt Zugriffsrechte bei der Ausführung für Windows.

6. Cluster-Instanzen

6.1. Standby-Datenbanken

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.

Mit Active Data Guard (ADG)

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.

Ohne Active Data Guard (DG)

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:

sqlplus> grant sysdba to checkmk;

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:

/etc/check_mk/mk_oracle.cfg
# Syntax:
# DBUSER='USER:PASSWORD:ROLE:HOST:PORT:TNSALIAS'
DBUSER='checkmk:myPassword: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.

Cluster-Services einrichten

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:

  • ORA .* RMAN Backup

  • ORA .* Job

  • ORA .* Tablespaces

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.

6.2. Real Application Cluster (RAC)

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.

Cluster-Services einrichten

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:

  • ASM .* Diskgroup

  • ORA .* Recovery Area

7. Benutzerdefinierte SQL-Abfragen (Custom SQLs)

7.1. Warum benutzerdefinierte SQL-Abfragen?

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.

Tip

Es gibt nur unter Linux, Solaris und AIX die Möglichkeit, benutzerdefinierte SQL-Abfragen einzusetzen. Unter Windows steht diese Option nicht zur Verfügung.

7.2. Einfache benutzerdefinierte SQL-Abfragen

SQL-Abfragen schreiben

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:

/etc/check_mk/MyCustomSQL.sql
/*Syntax help in comments. The first word is alwyas the key word and ends with a ":"*/

/*details:Text to display in the service detail output*/
prompt details: Some details for the service output;

/*perfdata:METRIKNAME=CURRENTVALUE;WARN;CRIT;MAX METRIKNAME=CURRENTVALUE2;WARN;CRIT;MAX*/
prompt perfdata:MyMetricName1=10;15;20;30 MyMetricName2=16;15;20;30;
prompt perfdata:MyMetricName3=21;15;20;30 MyMetricName4=15;15;20;30;

/*long:Text to display in the long output of the service*/
prompt long: Here comes some long output for the service;
prompt long: Here comes some more long output for the service;

/*exit:Status of the service as a number*/
prompt exit:2;

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:

  • details: Hier können Sie bestimmen, was im Summary des erzeugten Service ausgegeben werden soll. Die Zeile wird mit dem Schlüsselwort und einem Doppelpunkt eingeleitet. Der Rest der Zeile ergibt die Ausgabe.

  • perfdata: Metriken werden mit diesem Schlüsselwort übergeben. Innerhalb einer Zeile können Sie beliebig viele Metriken — getrennt durch ein Leerzeichen — erzeugen. Sie können die Ausgabe der Metriken auch über mehrere Zeilen verteilen. Beginnen Sie dabei einfach immer mit dem Schlüsselwort perfdata:.

  • long: Wenn der Service eine lange Ausgabe für das Feld Details haben soll, können Sie diese hier angeben. Auch dieses Schlüsselwort können Sie mehrmals verwenden, um mehrere Zeilen in den Details zu erzeugen.

  • exit: Soll die Ausgabe einen bestimmten Status haben, können Sie diesen hier bestimmen. Es stehen Ihnen dabei die bekannten Zuordnungen 0, 1, 2, 3 für die Status OK, WARN, CRIT, UNKNOWN zur Verfügung.

Tip

Das Schlüsselwort elapsed müssen Sie nicht manuell definieren. Es wird während der Laufzeit automatisch erzeugt, um zu prüfen, wie lange die von Ihnen definierten Anweisungen gebraucht haben.

Agentenplugin konfigurieren

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:

/etc/check_mk/mk_oracle.cfg
SQLS_SECTIONS="mycustomsection1"

mycustomsection1 () {
    SQLS_SIDS="INST1"
    SQLS_DIR="/etc/check_mk"
    SQLS_SQL="MyCustomSQL.sql"
}

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:

Der neue, durch benutzerdefinierte SQL-Abfragen erzeugte Service in der Service-Liste.

7.3. Erweiterte Optionen

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.

Tip

Variablen, die nur außerhalb oder nur innerhalb einer Sektions-Funktion gesetzt werden können, sind entsprechend markiert. Alle anderen können in beiden Bereichen definiert werden. Werden sie außerhalb einer Sektion gesetzt, gelten sie global für alle Sektionen.

Variable Kurzbeschreibung Optional

SQLS_SECTIONS

Die selbst definierten Sektions-Funktionen, die vom Agentenplugin ausgeführt werden sollen.
Diese Variable kann nur global gesetzt werden (außerhalb einer Sektions-Funktion).

Nein

SQLS_SIDS

Die Instanzen, welche die Sektion(en) ausführen sollen.

Nein

SQLS_DIR

Der Pfadname des Verzeichnisses, in dem die Dateien mit den benutzerdefinierten SQL-Abfragen abgelegt sind.

Nein

SQLS_SQL

Die Datei, welche die SQL-Anweisungen für eine Sektion enthält.

Nein

SQLS_SECTION_NAME

Der Name der Sektion, die Sie mit einem eigenen Check-Plugin für die benutzerdefinierten SQL-Abfragen auswerten.

Ja

SQLS_SECTION_SEP

Der Separator der einzelnen Elemente in einer Zeile der Ausgabe, definiert als dezimale ASCII-ID. Diese Variable kann nur in Verbindung mit der Variablen SQLS_SECTION_NAME benutzt werden. Wir empfehlen, für eigene Sektionen auch einen eigenen Separator festzulegen und dabei die ASCII-ID 124 für das Pipe-Zeichen (|) zu verwenden, da auch das Agentenplugin im Fehlerfall die Elemente der Ausgabe stets mit | trennt, im Format <SID>|FAILURE|<error description>. Die folgenden Zeichen dürfen nicht als Separator verwendet werden: ; [ ] =

Ja

SQLS_ITEM_NAME

Bestimmt einen Teil des generierten Service-Namens. Standardmäßig wird der Service-Name aus SID und dem Dateinamen mit den benutzerdefinierte SQL-Abfragen zusammengesetzt. Der Wert dieser Variable ersetzt im Service-Namen den Dateinamen.
Diese Variable kann nur lokal gesetzt werden (innerhalb einer Sektions-Funktion). Sie kann nicht zusammen mit der Variable SQLS_SECTION_NAME benutzt werden.

Ja

SQLS_MAX_CACHE_AGE

Erfüllt dieselbe Aufgabe, wie CACHE_MAXAGE — allerdings für die benutzerdefinierten SQL-Abfragen.

Ja

SQLS_DBUSER

Bestimmt einen individuellen Benutzer für eine Sektion.

Ja

SQLS_DBPASSWORD

Bestimmt das Passwort des mit SQLS_DBUSER festgelegten Benutzers.

Ja

SQLS_DBSYSCONNECT

Nur wenn der mit SQLS_DBUSER festgelegte Benutzer SYSDBA oder SYSOPER ist, müssen Sie mit dieser Variablen die zugehörige Rolle (SYSDBA oder SYSOPER) bestimmen.

Ja

SQLS_TNSALIAS

Bestimmt einen individuellen TNS-Alias für eine Sektion.

Ja

7.4. Eigene Check-Plugins nutzen

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.

8. Diagnosemöglichkeiten

Unter Linux erfolgt die Diagnose durch Aufruf des Agentenplugins mk_oracle mit verschiedenen Optionen. Mit mk_oracle --help können Sie sich eine Übersicht aller verfügbaren Optionen anzeigen lassen.

8.1. Verbindungstest

Tip

Der im folgenden beschriebene Verbindungstest überprüft auch, ob die notwendigen Zugriffsrechte bei der Ausführung unter Linux oder Windows 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.

Linux, Solaris, AIX

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 die Pfade zu seiner Konfigurationsdatei und zu den zwischengespeicherten Daten des Plugins bekannt gemacht werden muss. In der Ausgabe wurden die Dummy-Sektionen zugunsten der Lesbarkeit weggelassen.

Im Folgenden das Beispiel für einen Linux-Server mit systemd, auf dem das Agentenplugin alle 60 Sekunden asynchron ausgeführt wird:

root@linux# export MK_CONFDIR="/etc/check_mk/"; export MK_VARDIR="/var/lib/check_mk_agent"
root@linux# /usr/lib/check_mk_agent/plugins/60/mk_oracle -t --no-spool
---login----------------------------------------------------------------
    Operating System:       Linux
    ORACLE_HOME (oratab):   /u01/app/oracle/product/11.2.0/xe
    Logincheck to Instance: XE
    Version:                11.2
    Login ok User:          checkmk on ORA-SRV01 Instance XE
    SYNC_SECTIONS:          instance dataguard_stats processes longactivesessions sessions recovery_status undostat logswitches recovery_area performance
    ASYNC_SECTIONS:         tablespaces rman jobs ts_quotas resumable
------------------------------------------------------------------------

Auf einem Linux-Server mit xinetd rufen Sie stattdessen mk_oracle für den Verbindungstest wie folgt auf:

root@linux# /usr/lib/check_mk_agent/plugins/mk_oracle -t

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.

Windows

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:

C:\ProgramData\checkmk\agent\config\mk_oracle_cfg.ps1
# Syntax:
# $DBUSER = @("USERNAME", "PASSWORD")
$DBUSER = @("checkmk", "myPassword")

SYNC_SECTIONS = @("instance")
ASYNC_SECTIONS = @("")
DEBUG = 1

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:

PS C:\ProgramData\checkmk\agent\plugins\> .\mk_oracle.ps1
2020-08-23T12:48:20.3930944+02:00 DEBUG:value of DBVERSION software = xxx112020xxx
<<<oracle_instances>>>
2020-08-23T12:48:20.3930944+02:00 DEBUG:value of inst_name = xxxXExxx
2020-08-23T12:48:20.3930944+02:00 DEBUG:value of DBVERSION database = xxx112020xxx
2020-08-23T12:48:20.3930944+02:00 DEBUG:value of the_section = sql_instance
2020-08-23T12:48:20.3930944+02:00 DEBUG:now calling multiple SQL
2020-08-23T12:48:20.3930944+02:00 DEBUG:value of sql_connect in dbuser = checkmk/myPassword@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=1521))(CONNECT_DATA=(SID=XE))) as sysdba
<<<oracle_instance>>>
XE|FAILURE|...

8.2. Logging

Linux, Solaris, AIX

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. Vergessen Sie auch hier nicht die notwendigen Umgebungsvariablen: Auch im folgenden Beispiel wurde die Ausgabe der Sektionen übersprungen, um die Lesbarkeit zu erhöhen.

Hier der Aufruf für einen Linux-Server mit systemd, auf dem das Agentenplugin alle 60 Sekunden asynchron ausgeführt wird:

root@linux# export MK_CONFDIR="/etc/check_mk/"; export MK_VARDIR="/var/lib/check_mk_agent"
root@linux# /usr/lib/check_mk_agent/plugins/60/mk_oracle -l --no-spool
Start logging to file: /var/lib/check_mk_agent/log/mk_oracle.log

Hier der Aufruf von mk_oracle für das Logging auf einem Linux-Server mit xinetd:

root@linux# /usr/lib/check_mk_agent/plugins/mk_oracle -l

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

Windows

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.

8.3. Debugging

Linux, Solaris, AIX

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.

Im Folgenden das Beispiel für das Debugging auf einem Linux-Server mit systemd, auf dem das Agentenplugin alle 60 Sekunden asynchron ausgeführt wird:

root@linux# export MK_CONFDIR="/etc/check_mk/"; export MK_VARDIR="/var/lib/check_mk_agent"
root@linux# /usr/lib/check_mk_agent/plugins/60/mk_oracle -d --no-spool

Hier der Aufruf von mk_oracle für das Debugging auf einem Linux-Server mit xinetd:

root@linux# /usr/lib/check_mk_agent/plugins/mk_oracle -d

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

Windows

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:

PS C:\ProgramData\checkmk\agent\plugins\> Set-PSDebug -Trace 1
PS C:\ProgramData\checkmk\agent\plugins\> .\mk_oracle.ps1

8.4. Fehlermeldungen in Oracle Log-Dateien

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.

9. Dateien und Verzeichnisse

9.1. Auf dem Oracle-Host unter Linux, Solaris, AIX

Pfad Bedeutung

/usr/bin/check_mk_agent

Der Checkmk-Agent, welcher alle Daten zu dem Host sammelt.

/usr/lib/check_mk/plugins/mk_oracle

Das Oracle-Agentenplugin im üblichen Verzeichnis für Agentenplugins. Beachten Sie, dass der Pfadname unter AIX etwas anders ist: /usr/check_mk/lib/plugins/mk_oracle

/etc/check_mk/oracle.cfg

Die Konfigurationsdatei für das Agentenplugin. Auch hier unterscheidet sich AIX: /usr/check_mk/conf/mk_oracle.cfg

/etc/check_mk/sqlnet.ora

Die Konfigurationsdatei, welche für das Oracle-Wallet benötigt wird.

/etc/check_mk/tnsnames.ora

Die Konfigurationsdatei, welche TNS-Alias enthält. Beispieldateien liegen auch in der Oracle-Installation, aber da sich der Pfad je nach Installation unterscheidet, kann er nicht pauschal angegeben werden.

9.2. Auf dem Oracle-Host unter Windows

Pfad Bedeutung

C:\Program Files (x86)\checkmk\service\check_mk_agent.exe

Der Agent, welcher alle Daten zu dem Host sammelt.

C:\ProgramData\checkmk\agent\plugins\mk_oracle.ps1

Das Oracle-Agentenplugin im üblichen Verzeichnis für Agentenplugins.

C:\ProgramData\checkmk\agent\config\mk_oracle_cfg.ps1

Die Konfigurationsdatei für das Agentenplugin.

C:\ProgramData\checkmk\agent\config\sqlnet.ora

Die Konfigurationsdatei, welche für das Oracle-Wallet benötigt wird.

C:\ProgramData\checkmk\agent\config\tnsnames.ora

Die Konfigurationsdatei, welche TNS-Alias enthält. Beispieldateien liegen auch in der Oracle-Installation, aber da sich der Pfad je nach Installation unterscheidet, kann er nicht pauschal angegeben werden.

9.3. Auf dem Checkmk-Server

Pfad Bedeutung

~/share/check_mk/agents/plugins/mk_oracle

Das Agentenplugin für Unix-artige Systeme, welches auf dem Oracle-Host die Daten holt.

~/share/check_mk/agents/plugins/mk_oracle_crs

Dieses Agentenplugin für Unix-artige Systeme liefert Daten zu einem Oracle Cluster Manager.

~/share/check_mk/agents/windows/plugins/mk_oracle.ps1

Das Agentenplugin für Windows, welches auf dem Oracle-Host die Daten holt.

~/share/check_mk/agents/cfg_examples/

Hier befinden sich beispielhafte Konfigurationsdateien für Unix-artige Systeme in den Dateien mk_oracle.cfg, sqlnet.ora und tnsnames.ora.

~/share/check_mk/agents/windows/cfg_examples/mk_oracle_cfg.ps1

Eine beispielhafte Konfigurationsdatei für Windows.

Auf dieser Seite