Logo Oracle Deutschland   DBA Community  -  Dezember 2013
Oracle Enterprise Manager Cloud Control 12c: Es ist ganz einfach - Cloud Control Plug-ins selbst gemacht
von Ralf Durben, Oracle Deutschland B.V. & Co. KG

Mit Oracle Enterprise Manager Cloud Control lassen sich beliebige Systeme überwachen. Allerdings liefert Oracle die dafür notwendigen Plug-ins nur für die im Oracle Kosmos bekannten Produkte aus. Mittels eines neuen Tools und geschickter Nutzung von Cloud Control Features lassen sich in kurzer Zeit Monitoring Plug-ins für beliebige Systeme herstellen.

Dieser Tipp möchte Ihnen einen schnellen Einstieg in das Entwickeln eigener Plug-ins geben.

Inhalt

Dieser Tipp beinhaltet folgende Themen:

Grundprinzip des externen Monitorings in Cloud Control

Als externes Monitoring wird die Verfahrensweise einer Überwachung bezeichnet, bei der von einem System durch Zugriff von extern Daten entnommen werden. Diese Zugriffe können Skripte oder, im Fall einer Datenbank, SQL-Kommandos in einer Datenbanksitzung sein.

Bei Oracle Enterprise Manager Cloud Control wird dieser externe Zugriff vom Enterprise Manager Agenten durchgeführt. Dieser wird technisch gesehen mittels XML-Dateien für das Monitoring konfiguriert. Die XML-Dateien beinhalten den Namen eines Zieltyps mit allen Metriken samt Zugriffsmethoden, -intervallen und Bewertungsschwellenwerten. Natürlich muss auch auf der OMS Seite für den jeweiligen Zieltyp eine Datenstruktur im Repository geschaffen werden, damit die Monitoringdaten gespeichert werden können.

Ein Monitoring Plug-in beinhaltet also im Wesentlichen folgende Informationen:

  • Name des Zieltyps
  • Properties zum Anmelden an das Ziel, falls erforderlich
  • Metriken
    • Name der Metrik
    • Erfassungsintervall
    • Zugriffsmethode
    • Zugriffskommando
    • Schwellenwerte
Bei den Zugriffsmethoden unterstützt Cloud Control alle gängigen Verfahren, wie Betriebssystemkommandos, SQL, SNMP, HTTP, URLXML, URL Timing, DMS, JDBC, WBEM, JMX, Webservices, REST und WS-Management. Gerade über Betriebssystemkommandos steht der Überwachung eines beliebigen Systems eigentlich nichts im Wege.

Aufbau eines Plug-ins

Ein Plug-in besteht aus mehreren Dateien, die in einer komprimierten Datei mit der Endung "opar" zusammengefasst sind. Darunter sind die Konfigurationsdateien in einem speziellen XML-Format und die Skriptdateien, mit denen die Metriken abgefragt werden sollen.

Hilfmittel zum Erstellen von Plug-ins

Als Basis Hilfmittel steht das Extensibility Development Kit (EDK) zur Verfügung, welches eine Anleitung, Beispiele und vor allen die Tools zum Erstellen der OPAR-Datei zur Verfügung stellt. Neuerdings wurde diese rein kommandozeilenbasierte Variante durch eine grafische Unterstützung mit dem Namen Plug-in Builder erweitert. Der Plug-in Builder ist ein Modul im JDeveloper und seit Ende August 2013 im EDK enthalten.

Das EDK können Sie im Rahmen des Self Updates innerhalb von Cloud Control herunterladen. Abbildung 1 zeigt die entsprechende Zeile, wobei im vorliegenden System das EDK schon heruntergeladen wurde.



Nachdem das EDK nun auf der OMS Seite vorliegt, können Sie im Menüpunkt "Setup->Extensibility->Development Kit" weitere Anweisungen aufrufen.



Im Bereich "Deployment" finden Sie hinter dem ersten Bullet einen Downloadlink, mit dem Sie das EDK auf Ihren Client Rechner herunterladen können.



Jetzt fehlt Ihnen noch das Tool JDeveloper, welches Sie in der Version 11.1.1.7 benötigen. Die Studio Edition wird zwar in den Handbüchern empfohlen, ist aber recht groß und die schlanke Java Edition ist auch ausreichend. Entscheiden Sie sich also für eine dieser Editionen. Der Autor hat im folgenden mit der Java Edition gearbeitet.

Nachdem der JDeveloper installiert ist, entpacken Sie die EDK-Zip Datei, die Sie vom OMS heruntergeladen haben. Sie finden im Unterverzeichnis "doc"/"books" zwei Handbücher im Format PDF. Im Reference Guide in Kapitel 4 finden Sie die Anweisung, wie Sie den Plug-in Builder in einen bestehenden JDeveloper hineininstallieren. Das sind zum Zeitpunkt der Erstellung dieses Artikels schnelle sieben Schritte.

Bevor Sie den JDeveloper starten müssen Sie noch die Umgebungsvariable JAVA_HOME setzen. Auf Windows-Clients kann man das zum Beispiel leicht umsetzen mit einer BAT-Datei:

start_jdeveloper.bat:
set JAVA_HOME=C:\Users\rdurben\Downloads\12.1.0.3.0_edk_partner\jdeveloper\jdk1.6.0_43
C:\Users\rdurben\Downloads\12.1.0.3.0_edk_partner\jdeveloper\jdeveloper.exe
Den Erfolg können Sie daran messen, dass in JDeveloper nun unter dem Menüpunkt "New" die Kategorie "Enterprise Manager Plug-in" auftaucht.



Erstellen eines eigenen Plug-ins

Wenn Sie im JDeveloper ein neues Projekt der Kategorie "Enterprise Manager Plug-in" erstellen, werden alle notwendigen Dateien eines Monitoring Plug-ins erzeugt. Sie geben dazu verschiedene Namen (Produktname, Zieltypname, Firmenname,...) an, die später ihre Repräsentierung in den Plug-in Dateien wiederfinden.

Ein Monitoring Plug-in muss mindestens eine Metrik besitzen. Der Name dieser Metrik ist "Response" und wird zur Lebend-Überwachung verwendet, also um zu sehen, ob ein System verfügbar ist oder nicht. Im neu erstellten Plug-in ist auch eine solche Metrik enthalten, die in der Regel aber nicht unverändert verwendbar ist. Hier hilft der Blick in bestehende Plug-ins oder das Handbuch, um eine eigene Metrik zu erstellen.

Die Details dieser Metrik ändern Sie im JDeveloper Projekt unter "Projektname->Resources->oms->metadata->targetType->xxxxx.xml"

Beispiel 1: Eine Response Metrik auf Basis eines Perl Skripts:

Das folgende Fragment gibt die Definition einer Metrik auf Basis eines Perl Skripts an. Sie können dieses Fragment als Muster für weitere Metriken verwenden.

<Metric NAME="Response" TYPE="TABLE">
  <Display>
    <Label NLSID="NLSID_Response">Status</Label>
  </Display>
  <TableDescriptor>
    <ColumnDescriptor NAME="Status" TYPE="NUMBER" IS_KEY="FALSE">
      <Display>
        <Label NLSID="NLSID_Status">Status</Label>
      </Display>
    </ColumnDescriptor>
  </TableDescriptor>
  <QueryDescriptor FETCHLET_ID="OSLineToken">
   <Property NAME="perlBin" SCOPE="SYSTEMGLOBAL">perlBin</Property>
   <Property NAME="scriptsDir" SCOPE="SYSTEMGLOBAL">scriptsDir</Property>
   <Property NAME="command" SCOPE="GLOBAL">%perlBin%/perl %scriptsDir%/response_mytarget.pl</Property>
   <Property NAME="startsWith" SCOPE="GLOBAL">em_result=</Property>
   <Property NAME="warningStartsWith" SCOPE="GLOBAL">em_warning=</Property>
   <Property NAME="delimiter" SCOPE="GLOBAL">|</Property>
  </QueryDescriptor>
</Metric>
Das Perl Skript gibt dazu den entsprechenden Wert mit dem Prefix "em_result=" aus, also im einfachsten Beispiel sieht das Skript so aus (muss dann unter "Projektname->Resources->agent->scripts" gespeichert werden):

response_mytarget.pl:
print "em_result=3\n"
Beispiel 2: Eine Response Metrik auf Basis eines SQL Skripts (z.B. für die Überwachung von Datenbankbasierten Anwendungen):

Das folgende Fragment gibt die Definition einer Metrik auf Basis eines SQL Skripts an. Auch hier können Sie dieses Fragment als Muster für weitere Metriken verwenden. Im Beispiel wird einfach auf die View v$session zugegriffen.

<Metric NAME="Response" TYPE="TABLE">
  <Display>
    <Label NLSID="NLSID_Response">Status</Label>
  </Display>
    <TableDescriptor>
	<ColumnDescriptor NAME="Status" TYPE="NUMBER" IS_KEY="FALSE">
          <Display>
            <Label NLSID="betrieb_response_status">Status</Label>
          </Display>
        </ColumnDescriptor>
    </TableDescriptor>
    <QueryDescriptor FETCHLET_ID="SQL">
          <Property NAME="STATEMENT">
        <![CDATA[select count(*) as status from v$session]]>
      </Property>
    <Property NAME="MachineName" SCOPE="INSTANCE">MachineName</Property>
    <Property NAME="Port" SCOPE="INSTANCE">Port</Property>
    <Property NAME="SID" SCOPE="INSTANCE">SID</Property>
    <Property NAME="UserName" SCOPE="INSTANCE">UserName</Property>
    <Property NAME="password" SCOPE="INSTANCE">password</Property>
    <Property NAME="Role" SCOPE="INSTANCE" OPTIONAL="TRUE">Role</Property>
    </QueryDescriptor>
</Metric>    
In JDeveloper sieht das dann so aus:



Die obige SQL-Metrik greift auf Properties zu, die angeben, wie auf das Target zugegriffen werden kann. Diese Properties (Machine, Port, Username,...) müssen beim Hinzufügen eines neuen Targets in Cloud Control angegeben werden. Dazu müssen die Properties als Instance Properties definiert werden. Falls Ihr Target eine Datenbankanwendung ist, können Sie immer das folgende Fragment verwenden:

  <InstanceProperties>
    <InstanceProperty NAME="SID">
      <Display>
        <Label NLSID="SID">
          SID
        </Label>
      </Display>
    </InstanceProperty>
    <InstanceProperty NAME="UserName">
      <Display>
        <Label NLSID="UserName">
          UserName
        </Label>
      </Display>
    </InstanceProperty>
    <InstanceProperty NAME="password">
      <Display>
        <Label NLSID="password">
          password
        </Label>
      </Display>
    </InstanceProperty>
    <InstanceProperty NAME="MachineName">
      <Display>
        <Label NLSID="MachineName">
          MachineName
        </Label>
      </Display>
    </InstanceProperty>
    <InstanceProperty NAME="Port">
      <Display>
        <Label NLSID="Port">
          Port
        </Label>
      </Display>
    </InstanceProperty>
  </InstanceProperties>   
Der Screenshot zeigt, an welche Stelle in der XML-Sektion Sie dieses Fragment kopieren müssen.



Nachdem die Metrik definiert ist, müssen Sie jetzt noch das Erfassungsintervall und die Schwellenwerte für Warnmeldungen festlegen. Dazu navigieren Sie zu "Projektname->Resources->oms->default_collection->targetType->xxxxx.xml". Sie können die Angaben deklarativ machen,







oder direkt in XML:

  <CollectionItem NAME="Response">
    <Schedule>
      <IntervalSchedule INTERVAL="1"/>
    </Schedule>
    <Condition COLUMN_NAME="Status" CRITICAL="2" OPERATOR="LT" WARNING="4"
               MESSAGE="Problem mit Status"/>
  </CollectionItem>




Die Response Metrik wird also einmal pro Minute erfasst. Ein Wert unter 4 wird als Warnung interpretiert, ein Wert unter 2 gilt als kritisch.

Im Folgenden können nun beliebig viele Metriken erstellt werden - entweder durch die deklarative Angabe im Plugin-Builder, die dieser dann in korrektes XML umwandelt, oder durch direktes Einfügen von XML, zum Beispiel unter Verwendung obiger Fragmente. Ein weiterer Weg ist aber die Nutzung von Metric Extensions in Cloud Control. Dazu wird das neue Plug-in mit nur der Response Metrik in Cloud Control deployed (siehe unten) und weitere Metriken als "Metric Extension" erzeugt. Cloud Control bietet dazu eine sehr leicht zu bedienende Oberfläche an. Die neuen Metriken können direkt in Cloud Control getestet werden.

Da für die Metric Extensions letztlich auch nur wieder XML-Dateien angelegt werden, können diese nun herangezogen werden und die Metrikdefinitionen in den Plug-in Builder kopiert werden.

Deployment von eigenen Plug-ins

Wenn die einzelnen Definitionen für das Plug-in im Plug-in Builder vorliegen, erzeugen Sie mit einem Rechtsklick auf das Projekt und dem Menüpunkt "Create Plug-in Archive" eine Datei mit der Endung "opar".

Diese OPAR-Datei muss mit dem Enterprise Manager Command Line Interface (EMCLI) in das Repository importiert werden. Dazu wird das Kommando emcli import_update verwendet. Ein Beispiel:

emcli import_update -file=/pl/12.1.0.1.0_RD.WDG.xwdg_2000_0.opar -omslocal
Nach erfolgreichem Upload erscheint das neue Plug-in im Bereich "Setup->Extensibility->Plug-ins" und kann dort in den OMS deployed werden. Interessant ist hierbei, dass ein Deployment der ersten Version Ihres neuen Plug-ins auf Agenten nicht notwendig ist. Wenn Sie ein neues Ziel mit Ihrem neuen Zieltyp in Cloud Control hinzufügen, wird das neue Plug-in automatisch auf den angegebenen Agenten übertragen.

Aber Achtung: Wenn Sie für Ihr eigenes Plug-in eine neue Version erstellen und einspielen, findet hierfür keine automatische Übertragung auf die Agenten statt. In diesem Fall müssen Sie die neue Version manuell mit dem Button "Deploy" auf die Agenten bringen.

Fazit

Die Erstellung eigener Plug-ins erfordet zwar immer noch einige Handarbeit, ist aber mittlerweile viel einfacher als in früheren Versionen. Nach einer kurzen Einarbeitung können sehr schnell große Erfolge erzielt werden. Damit kann ein Monitoring durch Cloud Control auf viele sonst nicht unterstützte Systeme ausgedehnt werden.


Zurück zum Anfang des Artikels

Zurück zur Community-Seite