Wir nutzen Cookies, um Ihnen eine optimale Nutzung dieser Webseite zu ermöglichen. Mehr Informationen finden Sie im Datenschutzhinweis. Wir nehmen an, dass Sie damit einverstanden sind, falls Sie diese Webseite weiter besuchen.

Ihre Cookie-Einstellungen
Ihre Einstellungen wurden aktualisiert.
Damit die Änderungen wirksam werden, löschen Sie bitte Ihre Browser-Cookies und den Cache und laden dann die Seite neu.

Oracle-Datenbanken überwachen

Checkmk Manual

Suche im Handbuch

Dieser Artikel ist noch nicht fertig und nur ein Entwurf!

1. Einleitung

Checkmk bietet Ihnen umfangreiche Möglichkeiten Oracle-Datenbanken zu überwachen. So können Sie mit dem Plugin nicht nur Tablespaces oder die aktiven Sitzungen einer Datenbank abrufen, sondern zusätzlich noch viele andere Metriken. Eine vollständige Liste der Überwachungsmöglichkeiten können Sie in unserem 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 (einige der Plugins erst ab Version 1.6.0):

Um die Datenbanken überwachen zu können, brauchen Sie lediglich das Agenten-Plugin zusätzlich zu dem Agenten auf dem Datenbankserver. Unterstützt werden dafür zur Zeit die Betriebssysteme Linux, AIX, Solaris, HP-UX und Windows. Zusätzliche Software wird weder auf der Checkmk-Instanz 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 und danach die spezifischen für die jeweilige Betriebssystemgruppe. Bitte beachten Sie, dass die Einrichtung mittels der Agent Bakery derzeit nur für Linux, Solaris und AIX zur Verfügung steht.

2. Allgemeine Schritte zur ersten Einrichtung

2.1. Benutzer anlegen

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 keine RAC nutzen, legen Sie dafür auf jeder zu überwachenden Datenbank einen Benutzer an. Wie Sie sich auf eine Instanz einloggen, 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 Umbegungsvariable setzen, für die ein 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@myhost export ORACLE_SID=MYINST1

Danach loggen Sie sich auf die Instanz ein und legen einen Benutzer für das Monitoring an. Um an alle Daten zu kommen, werden auch die nachfolgenden Berechtigungen benötigt. In dem nachfolgendem 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 der Login auf eine bestimmte Instanz genau funktioniert, können Sie in der Dokumentation seitens Oracle erfahren.

Multitenant Datenbanken

Man kann auch den Login für Multitenant Datenbanken konfigurieren. Das wird normalerweise mit einem speziellen Benutzer und in der config mit dem Präfix C## getan.

2.2. Konfigurationsdatei und Benutzer anlegen

Nachdem Sie einen Benutzer angelegt haben, sorgen Sie als zweites dafür, dass das Agenten-Plugin 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 eine Konfigurationsdatei für Linux, AIX, Solaris oder für Windows an. In dem folgenden Beispiel sehen Sie die Datei für die unixoiden 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 Plugin zwingend benötigt. Alle anderen Optionen, die Sie unter unixoiden Systemen oder unter Windows verwenden können, sind optional.

2.3. Skript und Konfiguration auf den Host bringen

Nachdem Sie nun also einen Benutzer angelegt und diesen in der Konfigurationsdatei hinterlegt haben, bringen Sie noch das Plugin in das richtige Verzeichnis des Agenten. Wie der Pfad für Agentenplugins korrekt lautet, wird in den Artikel zu Linux und Windows beschrieben. Für Solaris und AIX können Sie in der Regel den gleichen Pfad nutzen, wie unter Linux. Achten Sie unter Linux (und auch unter AIX oder Solaris) darauf, dass das Plugin 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

2.4. Nutzung der Oracle-Wallet

Alternativ dazu, den Benutzer direkt und mit Passwort in einer Konfigurationsdatei anzugeben, können Sie auch die 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 Agent Bakery nutzen.

Die Oracle Wallet wiederum legt die Zugangsdaten verschlüsselt auf dem zu überwachenden Host ab, so dass sie nur benutzt werden können, aber keine Logindaten explizit bekannt gemacht werden müssen. Checkmk kann diese Wallet also nutzen, so dass die Zugangsdaten prinzipiell nur dem Datenbankadministrator (DBA) bekannt sein müssen. Legen Sie – oder der DBA – dazu eine Wallet auf dem entsprechenden Server an:

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

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

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

Damit das Plugin weiß, wo es nach der Wallet suchen muss, muss es zwei Dateien finden. Die erste Datei ist die sqlnet.ora in welcher hinterlegt wird, wo die 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 Agenten-Plugin diese Dateien findet, können Sie entweder den Pfad unter Linux, Solaris und AIX über die erweiterte Variable TNSALIAS setzen. Das ist vor allem dann von Vorteil, wenn die Dateien bereits existieren. Alternativ und 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 Plugin 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 zweite Datei die tnsnames.ora an. Beispiele zu einer Konfiguration finden Sie auf dem Checkmk-Server und auch auf dem Oracle-Host. Die genaue Syntax können Sie der Dokumentation seitens Oracle 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 letzten Schritt haben Sie die Voraussetzungen geschaffen, um die Zugangsdaten aus der Konfigurationsdatei des Agenten-Plugins herauszunehmen. Stattdessen tragen Sie lediglich noch ein / (Schrägstrich) ein:

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

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

3. Linux, AIX, Solaris

3.1. Plugin- und Konfigurationspfade

Unter unixoiden Systemen verwendet Checkmk ein einheitliches Plugin. Das reduziert zum einen den Aufwand der Pflege, da SQLs nicht dupliziert werden müssen und zum anderen, dass Sie nur ein einziges Plugin 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, wenn Sie diese nicht verändert haben:

OS Plugin-Pfad Konfigurationspfad
Linux, Solaris, HP-UX /usr/lib/check_mk_agent/plugins/ /etc/check_mk/
AIX /usr/check_mk/lib/plugins/ /usr/check_mk/conf/

3.2. Erweiterte Optionen

In der allgemeinen Einrichtung haben Sie bereits erste Variablen kennengelernt, um Überwachungsdaten von Ihren Oracle-Instanzen zu bekommen. Je nach Anwendungszenario werden Sie aber schnell weitere Möglichkeiten benötigen, um die Überwachung besser und individuell pro Instanz steuern zu können.

Erweiterte Benutzerkonfiguration

Mit dem Standardlogin 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. Bei 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 Logindaten werden nur für diese SID 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 TNSALIAS benutzt werden soll. Diese Angaben sind aber immer – im Gegensatz zu Benutzer und Passwort – optional. Zusätzlich zu dem obigen Beispiel kann also 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) voneinander getrennt.
  • Wird ein optionales Feld mittendrin ausgelassen, muss der Doppelpunkt geschrieben werden. Siehe DBUSER_MYINST2, bei dem keine spezielle Rolle angegeben wurde.
  • Werden ab einem bestimmten Punkt keine optionalen Felder mehr gebraucht, können Sie die Doppelpunkte weglassen. Siehe ASMUSER, bei dem weder der Host, noch der Port 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 Hier kann bestimmt werden, welche Instanzen überwacht werden sollen. Alle anderen werden dann ignoriert. Natürlich werden die Instanzen weiterhin auch nur dann überwacht, wenn sie auch von dem Plugin gefunden werden. Die Option eignet sich also sehr gut, wenn die Menge der zu überwachenden Instanzen kleiner ist, als die Anzahl derer, die ignoriert werden sollen.
SKIP_SIDS Alle Instanzen, die hier mit Leerzeichen separiert übergeben werden, werden komplett ignoriert und nicht überwacht. Diese Option eignet sich sehr gut, wenn die Anzahl der zu ignorierenden Instanzen kleiner ist, als diejenige, die überwacht werden soll.
EXCLUDE_{SID} Mit dieser Option können Sie Instanzen teilweise ausschließen. Zwar können Sie auch hier mit dem Wert ALL alle Sektionen ausschließen und daher dasselbe erreichen, als würden Sie sie zu SKIP_SIDS hinzufügen. Allerdings können Sie auch nur bestimmte Sektionen für bestimmte Instanzen abschalten und so nur eine Submenge des Möglichen überwachen. Wichtig: Eine ASM (+ASM) kann mit dieser Option nicht komplett abgeschaltet werden.

Sie werden es schon ahnen: Die Reihenfolge der Verarbeitung dieser Optionen bestimmt das Ergebnis. Tatsächlich werden die Angaben auch genau in der Reihenfolge pro Instanz verarbeitet, wie sie oben 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_ 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 dann auch ü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, werden entsprechend auch die zweite und dritte Zeile nicht mehr ausgewertet. Lediglich die vierte (=letzte) Zeile wird zu einem späteren Zeitpunkt berücksicht, 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 im vorherigen Abschnitt gelernt haben, ist es möglich nicht nur Instanzen komplett abzuschalten, sondern diese vielmehr auch nur teilweise zu überwachen. Auch sind die Einsatzzwecke vielfältig und vor allem dann sinnvoll, wenn sie bestimmte, lang laufende Sektionen nicht überall berücksichtigen wollen oder auf Testinstanzen nur grundlegende Informationen haben wollen. 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 SQLs 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, wie das bei der anderen Variable SYNC_SECTIONS der Fall ist.
ASYNC_ASM_SECTIONS Hier greift der gleiche Mechanismus für Sektionen der ASM, wie das bei der anderen Variable ASYNC_SECTIONS der Fall 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.

Der Mechanismus erlaubt es demnach in der Konfigurationsdatei einen Standard zu setzen und diesen bei Bedarf je Instanz noch einmal 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 zusätzlich auf allen regulären Instanzen ein Minimalset für die asynchronen Sektionen angegeben. Zusätzlich werden 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. INST2 wiederum fragt nur drei der vier asynchronen Sektionen ab, da jobs zusätzlich ausgeschlossen wurde. Und zuletzt wird der Cache von 10 Minuten auf 5 Minuten (=300 Sekunden) heruntergesetzt, da es möglich ist alle Daten in diesem Zeitraum zu holen.

Wichtig: Wenn Sie in der Konfigurationsdatei bestimmen, welche Sektionen auf welche Weise abgeholt werden sollen – Sie können ja auch eine normalerweise 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 rausnehmen, geben Sie die gesamte synchrone Liste an und lassen 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.

TNSALIAS und TNSADMIN konfigurieren

Coming soon. Hiermit kann dem TNSALIAS einer Instanz ein Post- oder Prefix hinzugefügt werden.

Zusätzlich kann man den TNSADMIN setzen, um die Pfad zu existierenden sqlnet.ora und tnsnames.ora anzugeben.

3.3. Entfernte Datenbanken überwachen

Unter unixoiden Systemen können Sie nicht nur lokal laufende Instanzen abrufen, sondern sich auch auf entfernte verbinden und diese abrufen. Dies ist zum Beispiel dann von Vorteil, wenn Sie keinen Zugriff auf das darunter liegende System haben, aber die Datenbank dennoch überwachen wollen. Um entfernte Datenbanken zu überwachen, gibt es allerdings die folgenden Voraussetzungen:

  • Die Linux AIO access library ist installiert. Unter RHEL/CentOS heißt das Paket libaio.
  • Der Instant Client for Oracle Database ist installiert.
  • SQLPlus ist in der Installation schon vorhanden oder muss ggf. als Erweiterungspaket zu dem Client installiert werden.

In der Regel sind die Voraussetzungen schon erfüllt, wenn sich auf dem Host, auf dem das Plugin ausgeführt werden soll, eine Oracle-Installation befindet. Andernfalls holen Sie dies über die entsprechenden Pakete nach.

Damit sich das Plugin auf die entfernte Datenbank verbinden kann, hinterlegen Sie zunächst in der Konfigurationsdatei die Zugangsdaten. Diese sind ähnlich zu den Angaben, die Sie bereits vom DBUSER kennen. 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'

In dem Beispiel sind zwei entfernte Instanzen konfiguriert. Damit jede Zeile eindeutig ist, wird jeder Variable eine ID übergeben. Diese können Sie frei wählen – sie muss lediglich pro Konfigurationsdatei einzigartig sein. Wie wahrscheinlich schon gesehen haben, gibt es auch bei den Werten nach der Portangabe noch weitere, die neu gesetzt wurden. Diese sind teilweise optional und teilweise notwendig, um eine Verbindung aufbauen zu können.

Der erste zusätzlich verwendete Wert (=PIGGYBACKHOST) bei der Instanz MYINST3 ist myOracleHost. Durch diese Angabe werden die Ergebnisse für die Abfrage 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 Plugin läuft. Auf der zweiten Instanz MYINST1 sehen Sie diese Angabe nicht; die Zurordnung zu einem anderen Host ist optional.

Der zweite neue Wert (=SID) ist die Angabe des Instanznamens. Da das Plugin auf dem entfernten Host nicht schauen kann, welche Instanzen dort 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 ebenfalls notwendig und dem Umstand geschuldet, dass viele Meta-Informationen nur zur Verfügung stehen, wenn man sich direkt auf dem Host befindet. Die Versionsangabe kann daher auch nicht weggelassen werden und bestimmt, welche SQLs an die Instanz übergeben werden können. In dem Beispiel verwenden beide 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 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.

Um auch das Programm sqlplus zu finden, geben Sie über die Variable REMOTE_ORACLE_HOME an, wo sich der Oracle-Client auf dem Host befindet, der das Plugin ausführt. Nur dann sind alle Ressourcen verfügbar, die für die Abfragen benötigt werden.

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

  • Sie können – logischerweise – entfernte Instanzen nicht per SKIP_SIDS ausschließen und brauchen sie im Gegenzug auf nicht bei ONLY_SIDS zu berücksichtigen.
  • Instanzen mit gleichem Namen dürfen nicht demselben Host zugewiesen werden. Das ist vor allem dann relevant, wenn Sie Instanzen von mehreren entfernten und/oder dem lokalen Host abrufen und dort identische Namen verwendet werden.

3.4. Einrichtung über die Agent Bakery

Die Einrichtung kann unter Linux, AIX, Solaris und HP-UX mit der Agent Bakery stark vereinfacht werden, da Syntaxfehler in den Konfigurationsdateien vermieden werden 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.

Nichtsdestotrotz können Sie nicht alle Funktionen des Plugins über die Agent Bakery konfigurieren. Zum einen, wenn es sich um veraltete Konfiguratinsoptionen handelt, die nur noch aus Kompatibilitätsgründen vorhanden sind. Diese lassen sich dann entsprechend durch die aktuellen Optionen ersetzen. Zum anderen, wenn es Funktionen sind, welche einen größeren Eingriff benötigen und eine klare Expertise voraussetzen. Entsprechend sind die Custom SQLs nicht direkt in der Agent Bakery konfigurierbar.

Über WATO ➳ Monitoring Agents ➳ Rules ➳ ORACLE Databases (Linux, Solaris, AIX) legen Sie eine Regel an. Hier finden Sie alle Optionen die Ihnen für die Konfiguration des Plugins zur Verfügung stehen:

Benutzer konfigurieren

Auch in der Agent Bakery haben Sie die Möglichkeit, Standardbenutzer und Ausnahmen für spezielle Instanzen anzulegen. Die Optionen, die Sie in der Konfigurationsdatei mit Doppelpunkt separiert finden, finden Sie hier als einzelne Optionen, die Sie dann entsprechend ausfüllen. In der einfachsten Konfiguration sieht das dann etwa so aus:

Natürlich können Sie auch hier die Wallet nutzen, indem Sie in dem Dropdown Authentication method einfach auf Use manually created ORACLE password wallet wechseln.

Die Konfiguration für eine ASM erledigen Sie analog über die Option Login for ASM und die Ausnahmen für spezifische Instanzen finden Sie bei Login for selected databases.

Erweiterte Optionen

In der folgenden Tabelle finden Sie die restlichen Optionen des Regelsets ORACLE Databases (Linux, Solaris, AIX) zusammen mit einem Verweis darauf, wo Sie eine Beschreibung zu der Option finden:

Option Beschreibung
Instances to monitor Diese Option fasst mehrere Optionen der Konfigurationsdatei zusammen, mit denen Sie Instanzen aus- oder einschließen können.
Add pre or postfix to TNSALIASes Mit dieser Optionen können Sie den TNSALIAS entweder global oder für eine spezifischen 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 enstprechen daher den beiden Variablen SYNC_SECTIONS und ASYNC_SECTIONS, sowie deren Gegenstück bei einer ASM aus dem Abschnitt, wo es um die zu holenden Daten geht.
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 das über diese Option machen. Eine genauere Beschreibun finden Sie bei den Optionen zu den Instanzen und Sektionen.
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 sqlnet.ora hinzugefügt und setzt ein Timeout für die Instanz selbst.
Remote instances Entfernte Instanzen konfigurieren Sie mit dieser Option. Sie enthält alle Elemente der Konfiguration, die Sie bereits kennen. Für die Bestimmung des ID der Variable haben Sie über die Unique ID die Wahl zwischen verschiedenen Möglichkeiten. Diese wirken sich lediglich auf die erwähnte ID aus und muss lediglich einzigartig sein.
ORACLE_HOME to use for remote access Hier können Sie bestimmen, wo das Agenten-Plugin das Programm sqlplus findet. Sie müssen es dann angeben, 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 Haben Sie bereits die entsprechenden Dateien an einem andern Ort angelegt, können Sie mit dieser Option – wie weiter oben beschrieben – auf die den Pfad zu den Dateien verweisen. Andernfalls wird unter /etc/check_mk/ danach gesucht.

4. Windows

4.1. Plugin- und Konfigurationspfade

Unter Windows verwendet Checkmk Powershell als Skriptsprache. Die Funktionalität ist an das Plugin unter unixoiden Systemen angelehnt, enthält aber nur einen Teil davon. Um das Plugin unter Windows nutzen zu können, benötigen Sie die folgenden Pfade, wenn Sie diese nicht verändert haben:

OS Plugin-Pfad Konfigurationspfad
Windows C:\ProgramData\checkmk\agent\plugins C:\ProgramData\checkmk\agent\plugins
Windows (Legacy Agent) C:\Program Files (x86)\check_mk\plugins\ C:\Program Files (x86)\check_mk\config\

Hinweis: Da der Legacy-Agent nur noch in sehr seltenen Ausnahmefällen benötigt wird, wird er bei der folgenden Beschreibung nicht beachtet. Es wird sich daher immer auf die aktuellen Architektur des Agenten bezogen.

Um das Plugin mk_oracle.ps1 zu aktivieren, kopieren Sie entweder das Plugin von C:\Program Files (x86)\checkmk\service\plugins\ in das oben beschriebene Pluginverzeichnis. Alternativ können Sie in der Konfigurationsdatei des Agenten auf die Datei im Installationspfad verweisen.

4.2. Besonderheiten unter Windows und Powershell

Windows verhindert normalerweise die Ausführung von 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, welche den checkmk-Agenten ausführt:

C:\ProgramData\checkmk\agent\> Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope LocalMachine
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:

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

Verständlicherweise haben Sie wahrscheinlich keine Lust, alle 60 Sekunden die Richtilinien umzustellen. Sie setzen daher eine permanente Ausnahme nur für die relevanten Skripte. Beachten Sie, dass hier auch das Konfigurationsskript zu den Ausnahmen hinzugefügt wird. Die Ausgabe wurde zu Gunsten der Lesbarkeit komplett weggelassen:

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

4.3. Erweiterte Optionen

In der allgemeinen Einrichtung haben Sie bereits erste Variablen kennengelernt, um Überwachungsdaten von Ihren Oracle-Instanzen zu bekommen. Weitere 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-Plugin nicht nur einen Standardlogin definieren, sondern auch individuelle 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 Logindaten werden nur für diese SID benutzt.
ASMUSER Spezielle Zugangsdaten für das Automatic Storage Management (ASM).

Wichtig: Auch hier kann für eine ASM 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 auch hier 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 Bespiel:

  • Sie können beliebig viele individuelle Zugangsdaten definieren. Diese werden immer dem Standard bevorzugt.
  • Jede Option wird in einer Liste definiert. Die Reihenfolge der Einträge darf nicht vertauscht werden.
  • Soll ein optionales Feld nicht verändert werden, aber ein danach folgendes, so müssen beide korrekt angegeben werden. Siehe 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. Siehe ASMUSER, bei dem nur die Rolle des Bentzers angegeben wurde.
  • Soll dem Bentzer keine spezielle Rolle zugewiesen werden, aber der 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 ja in dem Abschnitt für Linux bereits beschrieben. Zwei der drei Möglichkeiten, die sie von Linux kennen, können Sie auch hier verwenden:

Parameter Beschreibung
ONLY_SIDS Hier kann bestimmt werden, welche Instanzen überwacht werden sollen. Alle anderen werden dann ignoriert. Natürlich werden die Instanzen weiterhin auch nur dann überwacht, wenn sie auch von dem Plugin gefunden werden. Die Option eignet sich also sehr gut, wenn die Menge der zu überwachenden Instanzen kleiner ist, als die Anzahl derer, die ignoriert werden sollen.
EXCLUDE_{SID} Mit dieser Option können Sie Instanzen teilweise ausschließen. Zwar können Sie auch hier mit dem Wert ALL alle Sektionen ausschließen und daher dasselbe erreichen, als würden Sie sie zu SKIP_SIDS hinzufügen. Allerdings können Sie auch nur bestimmte Sektionen für bestimmte Instanzen abschalten und so nur eine Submenge des Möglichen überwachen. Wichtig: Eine ASM (+ASM) kann mit dieser Option nicht komplett abschalten.

Die Verarbeitung erfolgt in der oben angebenen Reihenfolge pro Instanz. Es wird also zuerst geprüft, ob sich die Instanz in ONLY_SIDS befindet und erst danach, ob bestimmte Sektionen ausgeschlossen werden sollen. Ist weiter die Variable EXCLUDE_ 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, während bei EXCLUDE_INST1 ein String ausreicht, bei dem Sektionen, separiert durch eine Leerzeichen, notiert werden.

Zu holende Daten bestimmen

Die Angabe, welche Sektionen überhaupt zu holen sind, erfolg äquivalent zu Linux. Daher hier nur ein Beispiel der Konfiguration:

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'

Wichtig: Wenn Sie in der Konfigurationsdatei bestimmen, welche Sektionen auf welche Weise abeholt werden sollen – Sie können ja auch eine normalerweise 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 rausnehmen, geben Sie die gesamte synchrone Liste an und lassen 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.

4.4. Entfernte Datenbanken überwachen

Die Überwachung entfernter Datenbanken ist derzeit nicht über das Windows-Plugin möglich. Wenn Sie entfernte Datenbanken überwachen wollen, benötigen Sie daher einen Host mit einem kompatiblen unixoiden Betriebssystem.

4.5. Einrichtung über die Agent Bakery

Zur Zeit steht die Einrichtung über die Agent Bakery nur für unixoide Systeme zur Verfügung.

5. Cluster-Instanzen

5.1. Standby-Datenbanken

Oracle unterstützt sogenannten Standby-Datenbanken, welche bestimmte Aufgaben erfüllen können und in der Regel schlicht Kopien von produtiven, 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 lizensiert und aktiviert, müssen Sie keinerlei Verändungen in der Konfiguration des Agenten-Plugins 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 Überwachungsdaten der Standby-Instanzen geholt werden soll, 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 der Standby-Server die Instanz noch nicht von MOUNTED auf OPEN umgestellt wurde.

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

sqlplus> grant sysdba to checkmk;

Damit die Daten im Fehlerfall von dem Agenten-Plugin auf dem Standby-Server abgefragt werden können, legen Sie den Benutzer auf der primären Instanz an und kopieren die Passwortdatei danach auf den Standby-Server. In der Konfigurationsdatei des Plugins setzen Sie noch die Rolle des Benutzers dann 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 wie immer weggelassen werden kann. Zusätzlich muss natürlich das Agenten-Plugin sowohl auf dem primären Oracle-Host, als auch auf den Standby-Hosts installiert sein.

Clustered 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 Checkplugins wurden bereits soweit vorbereitet, dass Sie auch als Clustered Services konfiguriert werden können. Legen Sie also einen Cluster-Host in Checkmk an und ordnen diesem Host die einzelnen Oracle-Hosts zu, denen die primäre und die Standy-Instanzen zugeordnet sind. Danach weisen Sie die folgenden Services diesem Cluster-Host zu:

  • ORA .* RMAN Backup
  • ORA .* Job
  • ORA .*Tablespaces

Danach brauchen Sie sich 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 oben erwähnten Services sichergestellt.

5.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 Agenten-Plugin nur einmal anzulegen. Lediglich das Agenten-Plugin 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 SCAN-Listeners. Nur dadurch ist gewährleistet, dass der Zugriff über das Plugin funktioniert.

Clustered Services einrichten

Auch bei einem RAC ist es sinnvoll bestimmte Services in einem Cluster-Host zusammenzufassen. 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

6. Eigene SQLs überwachen (Custom SQLs)

6.1. Warum eigene SQLs bestimmen?

Checkmk bietet mit dem offiziellen Plugin bereits eine große Menge an SQLs, 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 ab der 1.6.0 die Möglichkeit eigene SQLs zu definieren und mit dem Plugin mk_oracle abfragen zu lassen. Diese werden dann automatisch in der Weboberfläche als eigene Services erkannt und überwacht.

Wichtig: Es gibt nur unter Linux, AIX und Solaris die Möglichkeit, eigene SQLs abzufragen. Unter Windows steht diese Option nicht zur Verfügung.

6.2. Einfache eigene SQLs einbinden

Abzufragende SQLs schreiben

Die einfachste Weise so ein SQL anzubinden, ist die Nutzung des Check-Plugins Custom SQLs for Oracle DBs. Erstellen sie dafür zunächst die Datei mySQL.sql in dem Agenten-Konfigurationsverzeichnis des Hosts, auf dem das SQL ausgeführt werden soll. Nachfolgend ein Dummy, welcher die Syntax veranschaulicht:

/etc/check_mk/MySQL.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 Local-Checks vor allem mit Blick auf die Performance-Werte sehr ähnlich. 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 Status Detail 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: Performancedaten 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 einen Long Output haben soll, können Sie diesen hier angeben. Auch dieses Schlüsselwort können Sie mehrmals verwenden, um mehrere Zeilen im Long Output 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.

Hinweis: 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.

mk_oracle-Plugin konfigurieren

Nachdem Sie nun Ihr erstes, sehr einfaches SQL definiert haben, machen Sie es dem Plugin 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="MySQL.sql"
}

Mit der ersten Option (SQLS_SECTIONS) bestimmen Sie, welche individuellen Sektionen Sie ausführen lassen möchten. In dem Beispiel haben wir nur eine angegeben und diese dann direkt danach näher beschrieben. Jede Sektion ist also eigentlich eine kleine Funktion, die vom mk_oracle-Plugin aufgerufen wird.

In dieser Funktion können Sie dann weitere Details bestimmen und festlege, 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, damit 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:

6.3. Erweiterte Optionen

Die Möglichkeiten eigene SQLs zu überwachen gehen natürlich über den einfachen – oben gezeigten – Fall hinaus. Im nachfolgenden finden Sie eine kleine Übersicht der verfügbaren Variablen. Für eine ausführliche Beschreibung können Sie auch das Plugin mit der Option --help aufrufen. Wichtig: 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 von dem Plugin ausgeführt werden sollen. Wichtig: Diese Variable kann nur außerhalb einer Sektions-Funktion (=global) gesetzt werden nein
SQLS_SIDS Die Instanzen, welche die Sektion(en) ausführen sollen. Kann global oder pro Sektion gesetzt werden nein
SQLS_DIR Der Pfad, in dem die eigenen SQLs abgelegt wurden. Kann global oder pro Sektionen nein
SQLS_SQL Die Datei, welche die Anweisungen für eine Sektion enthält. nein
SQLS_PARAMETERS tbd ja
SQLS_SECTION_NAME Der Sektionssname, wenn Sie ein eigenes Checkplugin für die individuellen SQLs geschrieben haben. ja
SQLS_SECTION_SEP Der Separator der einzelnen Elemente in einer Zeile als Ascii-ID. Diese Variable kann nur in Verbindung mit der Variable SQLS_SECTION_NAME benutzt werden. ja
SQLS_ITEM_NAME Bestimmt einen individuellen Identifikator für den Servicenamen. Normalerweise wird die SID und der Dateiname der SQLs genommen. Wichtig: Diese Variable kann nicht zusammen mit der Variable SQLS_SECTION_NAME benutzt werden und kann auch nur innerhalb einer Sektions-Funktion gesetzt werden. ja
SQLS_ITEM_SID tbd ja
SQLS_MAX_CACHE_AGE Erfüllt dieselbe Aufgabe, wie CACHE_MAXAGE. ja
SQLS_DBUSER Bestimmt einen individuellen Benutzer für die Sektionen. ja
SQLS_DBPASSWORD Bestimmt ein individuelles Passwort für die Sektionen. ja
SQLS_DBSYSCONNECT Erweitert die Verbindung über eine SYS-Rolle für die Sektionen. ja
SQLS_TNSALIAS Setzt einen individuellen TNSALIAS für die Sektionen. ja

6.4. Eigene Checkplugins nutzen

Sollten Ihnen die Möglichkeiten der oben beschriebenen Syntax nicht ausreichen, können Sie über die Variable SQLS_SECTION_NAME auch eine eigene Sektionsname für ein oder mehrere SQLs ausgeben lassen. Das setzt allerdings voraus, dass Sie auch ein entsprechendes Checkplugin geschrieben und in Ihre Checkmk-Instanz eingebunden haben.

Haben Sie ein solche Checkplugin geschrieben, sind Sie komplett frei in der Syntax der Plugin-Ausgabe und können ganz eigene Wege gehen. Da dieser Weg der umfangreichste und auch schwierigste ist, ist er hier nur der Vollständigkeit erwähnt. Er setzt voraus, dass Sie wissen, wie man einen Checkmk-Check programmiert und in die Monitoring-Instanz einbindet. Danach ordnen Sie lediglich die individuellen SQLs mit den Variablen diesem Checkplugin zu.

7. Diagnosemöglichkeiten

7.1. Verbindung testen

Linux, AIX, Solaris

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. Mit der Option -t geben Sie die Details zu einer Verbindung aus. In der Ausgabe wurden die Dummy-Sektionen zugunsten der Lesbarkeit weggelassen. Beachten Sie außerdem, dass dem Plugin zuvor der Pfad zu seiner Konfigurationsdatei bekannt gemacht werden muss, da er sich darauf verlässt. Im Folgenden also das Beispiel auf einem Linux-Server:

root@linux# export MK_CONFDIR="/etc/check_mk/"
root@linux# /usr/lib/check_mk_agent/plugins/mk_oracle -t
---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
------------------------------------------------------------------------

Da man diesen Aufruf eher im Fehlerfall machen wird, werden Sie natürlich auch dann eine Ausgabe erhalten und in dieser zusätzlich noch die Connection-String, welcher für die Verbindung benutzt wurde und auch die ersten 100 Zeichen der Fehlermeldung, welche die Instanz zurückgegeben hat. Mit Hilfe dieser Informationen können Sie bereits schnell einfache Konfigurationsprobleme identifizieren und dann auch entsprechend beheben.

Windows

tbd

7.2. Ein Log erstellen lassen

Linux, AIX, Solaris

Falls der Fehler nicht durch die Prüfung einer einfachen Verbindung gefunden werden kann, können Sie als nächsten Schritt ein komplettes Log anlegen lassen, welches sämtliche Schritte des Plugins protokolliert. Auch hier benötigen Sie den Pfad zu der Konfigurationsdatei und zusätzlich auch den Pfad zu den zwischengespeicherten Daten des Plugins. Auch hier wurde die Ausgabe der Sektionen übersprungen, um die Lesbarkeit zu erhöhen:

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

Mit Hilfe dieses Logs können Sie im Zweifel sehr genau identifizieren, an welcher Zeile des Scripts das Problem auftritt.

Windows

tbd

7.3. Debugging des Plugins

Linux, AIX, Solaris

Wenn Sie auch mit Hilfe des Logs nicht an das Problem kommen, bietet das Plugin die komplette Ausgabe aller Schritte als letzte Möglichkeit der Fehleranalyse. 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 nicht die notwendige Umgebungsvariable:

root@linux# export MK_CONFDIR="/etc/check_mk/"
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 und jede Variable in Klartext lesbar.

Windows

tbd

8. Dateien und Verzeichnisse

8.1. Auf einem Oracle-Host unter Linux, AIX und Solaris

Pfad Bedeutung
/usr/bin/check_mk_agent Der Agent, welcher alle Daten zu dem Host sammelt.
/usr/lib/check_mk/plugins/mk_oracle Das übliche Verzeichnis, wo das Plugin liegt. Beachten Sie, dass der Pfad unter AIX etwas anders ist: /usr/check_mk/lib/plugins/mk_oracle
/etc/check_mk/oracle.cfg Die Konfigurationsdatei für das Plugin. Auch hier unterscheidet sich AIX: /usr/check_mk/conf/mk_oracle.cfg
/etc/check_mk/sqlnet.ora Die Konfigurationsdatei, welche für die Oracle Wallet benötigt wird.
/etc/check_mk/tnsnames.ora Die Konfigurationsdatei, welche einen Alias für ein Schema bestimmt, wenn Sie sie manuell angeben. Beispieldateien liegen auch in der Oracle-Installation, aber da sich der Pfad je nach Installation unterscheidet, kann er nicht pauschal angegeben werden.

8.2. Auf einem 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 übliche Verzeichnis, wo die Plugins abgelegt werden.
C:\ProgramData\checkmk\agent\config\mk_oracle_cfg.ps1 Die Konfigurationsdatei für das Plugin.
C:\ProgramData\checkmk\agent\config\sqlnet.ora Die Konfigurationsdatei, welche für die Oracle Wallet benötigt wird.
C:\ProgramData\checkmk\agent\config\tnsnames.ora Die Konfigurationsdatei, welche einen Alias für ein Schema bestimmt, wenn Sie sie manuell angeben. Beispieldateien liegen auch in der Oracle-Installation, aber da sich der Pfad je nach Installation unterscheidet, kann er nicht pauschal angegeben werden.

8.3. Auf dem Checkmk-Server

Pfad Bedeutung
share/check_mk/agents/cfg_examples/mk_oracle.cfg Hier befinden sich Beispiele zu der Konfigurations unter Linux, AIX oder Solaris. Eine solche Konfiguration benötigt das Plugin, um Daten abholen zu dürfen, da dort u.a. auch Zugangsdaten definiert werden können.
share/check_mk/agents/windows/cfg_examples/mk_oracle_cfg.ps1 Beispiele zu der Konfiguration unter Windows befinden sich hier.
share/check_mk/agents/plugins/mk_oracle Das Plugin, welches auf dem Oracle-Host die Daten holt.
share/check_mk/agents/plugins/mk_oracle_crs Dieses Plugin liefert Daten zu einem Oracle Cluster Manager.