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=MYINST1Danach 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> exitWie 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> exit2.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:
# Syntax:
# DBUSER='USERNAME:PASSWORD'
DBUSER='checkmk:myPassword'Für Windows sieht das sehr ähnlich aus. Hier setzen Sie die Variable in einem PowerShell-Skript:
# 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 -createAuf 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 myPasswordDamit 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:
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:
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:
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_walletDiese 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_walletAnschließ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.oraDie 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 |
|
|
Linux mit |
|
|
AIX |
|
|
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.
 |
Das Agentenplugin für Unix-artige Systeme |
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_oracle3.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 |
|---|---|
|
Der Standard, wenn keine individuellen Zugangsdaten für die Datenbankinstanz definiert sind. |
|
Zugangsdaten für eine ganz bestimmte Datenbankinstanz, in diesem Fall für die Instanz |
|
Spezielle Zugangsdaten für das Automatic Storage Management (ASM). |
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:
# 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 |
|---|---|
|
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. |
|
Im Gegensatz zu |
|
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 |
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:
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 |
|---|---|
|
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. |
|
Sektionen, die asynchron — das heißt nur alle x Minuten — abgefragt werden sollen.
Wie lange die Daten gültig sind, bestimmt die Variable |
|
Hier greift der gleiche Mechanismus für Sektionen der ASM, der bei der Variablen |
|
Hier greift der gleiche Mechanismus für Sektionen der ASM, der bei der Variablen |
|
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. |
|
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:
# 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.
|
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:
# 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:
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.
 |
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
sqlplusist 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:
# 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_SIDSausschließen und brauchen sie im Gegenzug auch nicht mitONLY_SIDSeinzuschließ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 |
|
|
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
BypassDiese 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
RemoteSignedVerstä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.ps14.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 |
|---|---|
|
Der Standard, wenn keine individuellen Zugangsdaten für die Datenbankinstanz definiert sind. |
|
Zugangsdaten für eine ganz bestimmte Datenbankinstanz, in diesem Fall für die Instanz |
|
Spezielle Zugangsdaten für das Automatic Storage Management (ASM). |
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:
# 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 derHOSTweiterhin auflocalhostgesetzt wird, obwohl nur derPORTverä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
HOSToderPORTangepasst 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 |
|---|---|
|
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. |
|
Da Ihnen unter Windows der Parameter |
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:
$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:
# 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' |
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:
# 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.
|
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:
# 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.
|
Wenn Sie die Prüfung der Zugriffsrechte abschalten, wird das Agentenplugin nicht mehr sicher ausgeführt. |
# Oracle plugin will not check if the used binaries are write-protected for non-admin users
$SKIP_ORACLE_SECURITY_CHECK=1Es 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:
plugins:
enabled: yes
execution:
- pattern: $CUSTOM_PLUGINS_PATH$\mk_oracle.ps1
async: yes
group: Users
run: true
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
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:
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:
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 |
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 |
Exclude some sections on certain instances |
Wenn Sie mit |
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 |
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 |
TNS_ADMIN to use for sqlnet.ora and tnsnames.ora (Linux/AIX/Solaris only) |
Falls die beiden Dateien in einem anderen Verzeichnis als |
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 |
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:
# 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 BackupORA .* JobORA .* 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 .* DiskgroupORA .* 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.
|
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:
/*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üsselwortperfdata:.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 Zuordnungen0,1,2,3für die Status OK, WARN, CRIT, UNKNOWN zur Verfügung.
|
Das Schlüsselwort |
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:
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:
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.
|
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 |
|---|---|---|
|
Die selbst definierten Sektions-Funktionen, die vom Agentenplugin ausgeführt werden sollen. |
Nein |
|
Die Instanzen, welche die Sektion(en) ausführen sollen. |
Nein |
|
Der Pfadname des Verzeichnisses, in dem die Dateien mit den benutzerdefinierten SQL-Abfragen abgelegt sind. |
Nein |
|
Die Datei, welche die SQL-Anweisungen für eine Sektion enthält. |
Nein |
|
Der Name der Sektion, die Sie mit einem eigenen Check-Plugin für die benutzerdefinierten SQL-Abfragen auswerten. |
Ja |
|
Der Separator der einzelnen Elemente in einer Zeile der Ausgabe, definiert als dezimale ASCII-ID.
Diese Variable kann nur in Verbindung mit der Variablen |
Ja |
|
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. |
Ja |
|
Erfüllt dieselbe Aufgabe, wie |
Ja |
|
Bestimmt einen individuellen Benutzer für eine Sektion. |
Ja |
|
Bestimmt das Passwort des mit |
Ja |
|
Nur wenn der mit |
Ja |
|
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
|
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 -tDa 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:
# Syntax:
# $DBUSER = @("USERNAME", "PASSWORD")
$DBUSER = @("checkmk", "myPassword")
SYNC_SECTIONS = @("instance")
ASYNC_SECTIONS = @("")
DEBUG = 1Fü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.logHier 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 -lMit 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-spoolHier 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 -dWichtig: 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.ps18.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 |
|---|---|
|
Der Checkmk-Agent, welcher alle Daten zu dem Host sammelt. |
|
Das Oracle-Agentenplugin im üblichen Verzeichnis für Agentenplugins.
Beachten Sie, dass der Pfadname unter AIX etwas anders ist: |
|
Die Konfigurationsdatei für das Agentenplugin.
Auch hier unterscheidet sich AIX: |
|
Die Konfigurationsdatei, welche für das Oracle-Wallet benötigt wird. |
|
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 |
|---|---|
|
Der Agent, welcher alle Daten zu dem Host sammelt. |
|
Das Oracle-Agentenplugin im üblichen Verzeichnis für Agentenplugins. |
|
Die Konfigurationsdatei für das Agentenplugin. |
|
Die Konfigurationsdatei, welche für das Oracle-Wallet benötigt wird. |
|
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 |
|---|---|
|
Das Agentenplugin für Unix-artige Systeme, welches auf dem Oracle-Host die Daten holt. |
|
Dieses Agentenplugin für Unix-artige Systeme liefert Daten zu einem Oracle Cluster Manager. |
|
Das Agentenplugin für Windows, welches auf dem Oracle-Host die Daten holt. |
|
Hier befinden sich beispielhafte Konfigurationsdateien für Unix-artige Systeme in den Dateien |
|
Eine beispielhafte Konfigurationsdatei für Windows. |