Überblick
B2B by Practice ist durch Schnittstellen und eine zusätzliche Webapplikation (external-monitoring.war) darauf vorbereitet, zentral durch Nagios, SAP Solution Manager oder andere Tools (im Folgenden Überwachungstool genannt) überwacht zu werden. Die Webapplikation kann durch ihren Service Provider bereitgestellt werden. Alternativ können Sie auch die Webapplikation selbst aus dem B2B by Practice Quelltext erzeugen, worauf hier aber nicht eingegangen wird.
Voraussetzung: Die External Monitoring Webapplikation benötigt mindestens Java 1.5.Customizing
Aufbau der Zustands-XML Datei
Der Zustand des B2B by Practice Systems wird vom Überwachungstool per http-POST erfragt. Die Antwort der External Monitoring Webapplikation ist im XML-Format und wie folgt:
<?xml version="1.0" encoding="UTF-8"?>
<scenario>
<scenname>B2BBP</scenname>
<sceninst>1</sceninst>
<scenversion>1</scenversion>
<component>
<compname>ASERVICE</compname><compversion>1</compversion>
<compdesc>Aktive B2BBBP-Services</compdesc>
<comphost/>
<compinst/>
<messages>
<message>
<messalert>ERROR</messalert>
<messseverity>255</messseverity>
<messarea/>
<messnumber/>
<messparam1/>
<messparam2/>
<messparam3/>
<messparam4/>
<messtext>Node unknown Error getting ClusterNode Info from URL
[http://localhost:8080/b2bbp-engine/clusternodeinfo] please check URL,
Username and Password.</messtext>
</message>
</messages>
</component>
...
Im xml-Tag „scenario“ ist eine Gruppe von Komponenten beschrieben, in diesem Fall alle durch eine Instanz der External Monitoring überwachte Komponenten (Tag „component“). Hier ist nur eine Komponente beispielhaft ausgewählt, nämlich ASERVICE. In „messalert“ können die Werte „ERROR“ und „OKAY“ stehen. In „messseverity“ ist die Schwere des Fehlers auf einer Skala von „0“ bis „255“ abgebildet. In „messtext“ ist eine ausführlichere Fehlermeldung enthalten.
SAP Solution Manager
Initial benötigt der SAP Solution Manager ein Customizing, das zur Beschreibung der zu überwachenden Dienste dient. Dieses Customizing kann aus der Webapplikation exportiert werden und anschließend manuell importiert werden.
Nagios
Für die Überwachung mit Nagios ist ein zusätzliches Script erforderlich, um die XML Datei, die den Zustand enthält zu parsen und entsprechend an Nagios weiterreicht.
Einrichtung
Zuerst müssen Einstellungen an B2B by Practice vorgenommen werden, danach wird die Installation und Konfiguration der External Monitoring Webapplikation beschrieben.
Konfiguration von B2B by Practice
Die restlichen Konfigurationsschritte erfolgen über die B2B by Practice GUI. Zum prinzipiellen Aktivieren der ASERVICE-Überwachung muss die globale Eigenschaft B3P_ENABLE_ACTIVITY_MONITOR, falls nicht vorhanden hinzugefügt, und dann auf den Wert true gesetzt werden. Des Weiteren kann der Timeout für die Überwachung der aktiven Services über den globalen Parameter B3P_MONITORING_EXECUTION_TIMEOUT konfiguriert werden (Ganzzahl in Sekunden), der als Standardwert beträgt 300 Sekunden.
Um die Überwachung der aktiven Services auf den einzelnen Knoten zu aktivieren muss die GlobalProperty: B3P_ENABLE_ACTIVITY_MONITOR auf den Wert True gesetzt werden. Ist die Eigenschaft nicht gesetzt, werden die aktiven Services nicht überwacht (default ist also keine Überwachung aus Performancegründen).
Über den Parameter B3P_MONITORING_EXECUTION_TIMEOUT kann das Timeout für die aktiven Services beeinflusst werden. Da ein Service kurzfristig als inaktiv gekennzeichnet werden kann, während er aufgrund der Aktivität anderer Services geskippt wird, oder für eine längere Zeit ausgeführt wird, kann über diese Einstellung geregelt werden wie lange der Service zusätzlich zu seinem Pollintervall Zeit hat um wieder ausgeführt zu werden Ist diese GlobalProperty nicht vorhanden wird ein Standardwert von 300 Sekunden verwendet. Das bedeutet, das ein Service 300 Sekunden + Pollintervall zwischen 2 Ausführungen Zeit hat.
In der Extension EXTERNAL_MONITORING werden die zu überwachenden Komponenten konfiguriert, hier nun in Einzelschritten erklärt. Zuerst werden die zu testenden Komponenten definiert, d.h. Alias-Namen werden Java-Klassen nach dem Schema class=ALIAS|package.classname
zugeordnet:
class=ASERVICE|org.b2bbp.external.monitoring.components.ActiveServiceComponent
class=INDEXCOM|org.b2bbp.external.monitoring.components.IndexComponent
class=SYSAVAIL|org.b2bbp.external.monitoring.components.SystemAvailabilityComponent
class=PROCERR|org.b2bbp.external.monitoring.components.ProcessingErrorComponent
class=QUEUECOM|org.b2bbp.external.monitoring.components.QueueComponent
class=SYSERROR|org.b2bbp.external.monitoring.components.SystemErrorComponent
Zu beachten ist, dass der Alias-Name maximal 8 Zeichen lang sein darf. Hier eine genauere Beschreibung der momentan in B2B by Practice verfügbaren Komponenten, inkl. deren spezifischen Konfigurationsmöglichkeiten:
Komponente | Beschreibung |
ActiveServiceComponent | Überprüft die Aktivität von aktiven Services anhand des B2B by Practice-Locking-Mechanismus: ASERVICE=http://localhost:8080/b2bbp-engine/clusternodeinfo Sollen mehrere Cluster-Instanzen überprüft werden, kann der Eintrag mehrfach auftauchen. |
IndexComponent | Überprüft die Größe der Index-Tabelle, d.h. die Menge der noch zu indizierenden Nachrichten: INDEXCOM.indexTableMaxEntries=200 Wird dieser Schwellwert überschritten, wird ein Fehler gemeldet. |
SystemAvailabilityComponent | Überprüft die generelle Erreichbarkeit einer Clusterinstanz. Parameter: SYSAVAIL.systems=127.0.0.1:8080 SYSAVAIL.requestWarningTimeMS=500 SYSAVAIL.requestErrorTimeMS=2500 systems: gibt das zu überprüfende System als host:port-Kombination an. Sollen mehrere Systeme überwacht werden, kann der Eintrag einfach wiederholt werden, z.B. kann in einer zusätzlichen Zeile "SYSAVAIL.systems=127.0.0.1:8070" eingetragen werden. requestWarningTimeMS: ist der Schwellwert in Millisekunden für eine Warnung. requestErrorTimeMS: ist der Schwellwert in Millisekunden für eine Fehlermeldung. |
ProcessingErrorComponent | Überprüft die Anzahl an fehlerhaften Nachrichten: PROCERR.errorThreshold=60 PROCERR.interval=60 Sind in den vergangenen interval Sekunden mehr als errorThreshold fehlerhaft verarbeitete Nachrichten aufgetreten, wird ein Fehler gemeldet. |
QueueComponent | Überprüft die Anzahl der Nachrichten in der Queue, d.h. die Menge der noch zu verarbeitenden Nachrichten: Der Parameter QUEUECOM.thresholdAll=100 gibt an, ab welchem Schwellwert die Komponente QueueComponent detailliertere Überprüfungen vornimmt. Ist dies der Fall, dann geben die Parameter QUEUECOM.thresholdS=50 QUEUECOM.thresholdM=25 QUEUECOM.thresholdL=15 QUEUECOM.thresholdX=5 die Schwellwerte für die einzelnen Queues (S, M, L, X) vor, bei deren Erreichen ein Fehler gemeldet wird. |
SystemErrorComponent | Überprüft die Systemfehlermeldungen: SYSERROR.errorThreshold=1000 SYSERROR.interval=60 Die Parameter haben dieselbe Bedeutung wie bei der Komponente ProcessingErrorComponent, nur dass sie sich auf Systemfehlermeldungen beziehen. |
CcmIndexSyncComponent | Überprüft die Größe der CCM Index-Tabelle, d.h. die Menge der noch zu indizierenden Nachrichten: CCMISYNC.thresholdWarn=200 CCMISYNC.thresholdCritical=500 Wird der Warnungs-Schwellwert (thresholdWarn) überschritten, wird eine Warnung gemeldet. Wird der kritische Schwellwert (thresholdCritical) überschritten, wird ein Fehler gemeldet |
Eine Beispielhafte Konfiguration für die Extension EXTERNAL_MONITORING kann also so aussehen:
class=ASERVICE|org.b2bbp.external.monitoring.components.ActiveServiceComponent
class=INDEXCOM|org.b2bbp.external.monitoring.components.IndexComponent
class=SYSAVAIL|org.b2bbp.external.monitoring.components.SystemAvailabilityComponent
class=PROCERR|org.b2bbp.external.monitoring.components.ProcessingErrorComponent
class=QUEUECOM|org.b2bbp.external.monitoring.components.QueueComponent
class=SYSERROR|org.b2bbp.external.monitoring.components.SystemErrorComponent
class=CCMISYNC|org.b2bbp.external.monitoring.components.CcmIndexSyncComponent
SYSAVAIL.systems=127.0.0.1:8070
SYSAVAIL.systems=127.0.0.1:8080
SYSAVAIL.requestWarningTimeMS=500
SYSAVAIL.requestErrorTimeMS=2500
INDEXCOM.indexTableMaxEntries=200
ASERVICE=http://localhost:8070/b2bbp-engine/clusternodeinfo
ASERVICE=http://localhost:8080/b2bbp-engine/clusternodeinfo
PROCERR.errorThreshold=0
PROCERR.interval=60
SYSERROR.errorThreshold=1000
SYSERROR.interval=60
QUEUECOM.thresholdAll=100
QUEUECOM.thresholdS=50
QUEUECOM.thresholdM=25
QUEUECOM.thresholdL=15
QUEUECOM.thresholdX=5
CCMISYNC.thresholdWarn=1000
External Monitoring LockStat
Das ExternalMonitoring kann über den LOCKSTAT-Check die Dauer der Sperrung eines oder mehrerer Einträge in der Lock-Tabelle überwachen. Die nachfolgende Konfiguration zeigt die Überwachung von 3 speziellen Locks (CRAWLER;QUEUE;INDEX), für die ein Fehler (MonitoringEintrag) erstellt wird, wenn diese länger als 10 Sekunden geloggt sind.
class=LOCKSTAT|org.b2bbp.external.monitoring.components.LockStateComponent
LOCKSTAT.LOCKNAMES=CRAWLER;QUEUE;INDEX
LOCKSTAT.CRAWLER=10
LOCKSTAT.QUEUE=10
LOCKSTAT.INDEX=10
Installation der External Monitoring Webapplikation
Die Webapplikation dient der zur Überwachung von einer oder mehreren B2B by Practice Instanzen. Sie kann entweder zusammen mit einer anderen B2B by Practice Instanz (also im gleichen Applikationsserver) oder einem getrennten Applikationsserver betrieben werden, z.B. in Tomcat:
-
Die war-Datei herunterladen: PublicDL/B2B-ExternalMonitoring
-
Deployen der Webapplikation: Die Datei external-monitoring.war in den tomcat\webapps-Ordner kopieren. Unter Umständen muss Tomcat neu gestartet werden.
-
Datenbank-Verbindung: Dies wird in tomcat\conf\Catalina\localhost\external-monitoring.xml konfiguriert. Es muss die Datenbank des zu überwachenden B2B by Practice-Systems konfiguriert werden. Dies kann z.B. einfach durch Kopieren des <Resource name=“jdbc/b2bbp“ … />-Tags aus der b2bbp-engine.xml und anschließendes Ersetzen (falls schon ein “Resource”-Tag enthalten ist) erreicht werden. Während dieser Anpassung sollte Tomcat gestoppt sein.
Durch Aufruf von http://localhost:8080/external-monitoring/emoni (Host und Port stammen vom Tomcat, auf dem die External Monitoring Webapplikation läuft, der Pfad wird analog zum Namen der XML Datei wie unter 2 Beschrieben generiert) kann die Funktionsfähigkeit überprüft werden. Das Ergebnis kann so aussehen:
<TestResult>
<Component>
<name>QUEUECOM</name>
<version>1</version>
<comphost/>
<compinst/>
<description>B2BBP-Processing Queue</description>
<type>1</type>
<messages>
<Message>
<messalert>OKAY</messalert>
<messseverity>0</messseverity>
<messarea/>
<messageId/>
<messtext>B2Bs processing-queue is empty</messtext>
</Message>
</messages>
</Component>
<Component>
<name>SYSERROR</name>
...
</Component>
...
</TestResult>
In diesem Beispiel sind keine Fehler zu sehen.
Anbindung an Überwachungstool
Anbindung an den SAP Solution Manager
Zuerst muss das Customizing der External Monitoring Webapplikation exportiert werden. Rufen Sie hierzu die URL http://localhost:8080/external-monitoring/solutionmanager (die wie oben beschrieben gebildet wird) in ihrem Browser auf und speichern Sie die XML-Datei ab. Diese XML-Datei kann so aussehen:
<customizing>
<control>
<grmgruns>X</grmgruns>
<runlog></runlog>
<errorlog></errorlog>
</control>
<scenarios>
<scenario>
<scenname>b2bbp</scenname>
<scenversion/>
<sceninst>1</sceninst>
<scentype>URL</scentype>
<scenstarturl>[http://localhost:8070/external-monitoring/solutionmanager]</scenstarturl>
<scenstartmode>Not Used</scenstartmode>
<scentexts>
<scentext>
<scenlangu>E</scenlangu>
<scendesc>B2B_ace</scendesc>
</scentext>
</scentexts>
<components>
<component>
<compname>QUEUECOM</compname>
<compversion>1</compversion>
<comptype>1</comptype>
<comptexts>
<comptext>
<compdesc>B2BBP-Processing Queue</compdesc>
</comptext>
</comptexts>
<properties>
<property>
<propname>Unknown</propname>
<propvallue>Unknown</propvallue>
</property>
</properties>
</component>
<component>
<compname>SYSERROR</compname>
...
</component>
...
</components>
</scenario>
</scenarios>
</30_customizing>
Bevor Sie diese in den SAP Solution Manager importieren, können Sie das Customizing ggf. anpassen, z.B. bei Bedarf die URL anpassen.
Bei Fragen können Sie sich gerne an die EXXETA AG wenden, welche die Solution Manager Anbindung implementiert hat.
Anbindung an Nagios
Vorraussetzungen:
Perl Module auf Nagios Server:
Nagios::Plugin
XML::LibXML
Ein rudimentäres Skript zum Auswerten der XML Datei könnte so aussehen:
#!/usr/bin/perl -w
# check_b2b
#
# Nagios Plugin fuer die Statusabfrage des B2B Servers
#
# Module: Nagios::Plugin und XML::LibXML
#
# Autor: Thorsten Gowik
# Kontakt: Thorsten.Gowik@eswe.com
#
# Lizenz: GPL
#
# Version 0.3 dschlich@next-level-integration.com:
# Changed variable declaration to "our local"
# to fix errors of Nagios ePN Perl interpreter
#
# Version 0.2 DebugCode entfernt
# Verbesserung durch Subroutinen
#
# Version 0.1 Start Release
use strict;
use warnings;
use Nagios::Plugin;
use XML::LibXML;
use vars qw($VERSION $PROGNAME $verbose $critical $timeout $result);
local our ($message, $return);
$VERSION = 0.3;
$PROGNAME = "check_b2b";
# instantiate Nagios::Plugin
my $p = Nagios::Plugin->new(
usage => "Usage: %s [ -v|--verbose ] [-H <host>] [-t <timeout>]",
version => $VERSION,
blurb => 'Dieses Plugin ruft die XML Status Seite des B2B Systems ab und uebergibt die Infos an den Nagios Server.'
);
# add arguments
$p->add_arg(
spec => 'host|H=s',
help =>
qq{-H, --host=STRING
Specify the host on the command line.},
);
$p->getopts;
my $host = $p->opts->host;
my $url = "http:$host:8080/external-monitoring/emoni";
local our $i = 0;
local our $j = 0;
my $parser = XML::LibXML->new();
local our $dom = $parser->load_xml(
location => $url
);
local our $query1 = "//Message/messalert/text()";
local our $query2 = "//Message[messalert/text() = 'ERROR'] /messtext/text()";
jquery() ;
emassage() ;
$p->nagios_exit(
return_code => $return,
message => $message
);
sub jquery {
foreach ($dom->findnodes($query1)) {
if ($_->data eq 'ERROR') {
$j++;
}
else {
$i++;
}
}
}
sub emassage {
if ($j == 1) {
$message = $_->data . "\n" foreach ($dom->findnodes($query2));
$return = 'CRITICAL';
}
elsif ($j > 1) {
$message = "$j Kritische Dienste gefunden!";
$return = 'CRITICAL';
}
else {
$message = "$i Services mit Status OKAY gefunden!";
$return = 'OK';
}
};
Dieses Perl-Skript lädt die XML Datei und prüft, ob eine Komponente den Status ERROR enthält. In diesem Fall wird CRITICAL an Nagios gesendet. Der Link zur ExternalMonitoring Zustands-XML muss ggf. angepasst werden.
Dieses Script wird mit dem Dateinamen check_b2b_em im Verzeichnis /usr/lib/nagios/plugins/ (Debian) bzw./usr/lib64/nagios/plugins/ (Redhat) gespeichert.
Des Weiteren muss eine Nagios Konfiguration angelegt werden. Dazu wird eine neue Datei unter /etc/nagios3/conf.d/b2b-extenal-monitoring.cfg erstellt. Die Datei sollte folgenden Inhalt aufweisen:
define command{
command_name check_b2b_em
command_line $USER1$/check_b2b_em-H '$HOSTADDRESS$'
}
define host{
host_name b2b.domain.tdl
alias B2B System
address 1.2.3.4
…
}
define service {
host_name b2b.domain.tdl
service_description B2B External Monitoring
check_command check_b2b_em
…
}
Auswertung
Bei der Auswertung sind folgende Antworten für die einzelnen Komponenten möglich:
Komponente | Message Alert | Severity | MessageText (Exemplarisch, da von Customizing abhängig) |
ASERVICE | |||
ERROR | 255 | Error getting ClusterNode Info, please check if the globalProperties: B3P_RELOAD_USER and B3P_RELOAD_PASSW have been set correctly. | |
OKAY | 0 | All active B2B Services where active during their MinActiveIntervall. | |
ERROR | 255 | Node with URL: localhost could not be reached, please check Customizing, Network and if the Node running | |
ERROR | 255 | Error reading Cluster Node URLS from EXTERNAL_MONITORING Extension. | |
INDEXCOM | |||
ERROR | 255 | ERROR in B2B-Customizing there is missing an entry INDEXCOM.indexTableMaxEntries=MAXVALUE in EXTERNAL_MONITORING Extension | |
OKAY | 0 | B2B-Index contains 0 Entries, that is below the max size of 200 | |
ERROR | 255 | B2B-Index contains 100 Entries, that is more than the max size of 50 | |
PROCERR | |||
ERROR | 255 | ERROR in B2B-Customizing, there is missing an entry PROCERR.errorThreshold=MAXVALUE in EXTERNAL_MONITORING Extension | |
OKAY | 0 | In B2B occured 0 ProcessingErrors in the last 60 minutes. | |
ERROR | 255 | In B2B occured 100 ProcessingErrors in the last 60 minutes. | |
QUEUECOM | |||
Error | 255 | ERROR in B2B-Customizing, QUEUECOM needs the following parameters in SOLUTION_MANAGER Extension: QUEUECOM.thresholdAll, QUEUECOM.thresholdS, QUEUECOM.thresholdM, QUEUECOM.thresholdL, QUEUECOM.thresholdX | |
OKAY | 0 | B2Bs processing-queue is empty | |
ERROR | 255 | There are 0 small Messages, threshold: 50; 0 medium Messages threshold: 25; 150 large Messages threshold: 15; 0 exclusive Messages threshold: 5 in the B2B processing queue, one of the values is larger than the error threshold. | |
OKAY | 0 | There are 0 small Messages, threshold: 50; 0 medium Messages threshold: 25; 150 large Messages threshold: 15; 0 exclusive Messages threshold: 5 in the B2B processing queue. Fall 4. kann eintreten wenn der Schwellwert für alle < Summe aller einzelnen Schwellwerte je Nachrichtengröße |
|
SYSAVAIL | |||
ERROR | 255 | ERROR in B2B-Customizing, there is missing an entry SYSAVAIL.requestWarningTimeMS=MilliSeconds or SYSAVAIL.requestErrorTimeMS=MilliSeconds in EXTERNAL_MONITORING Extension | |
ERROR | 255 | System 127.0.0.1 could not be reached on port 8080. It is either not active or not reachable of the network | |
ERROR | 128 | The Request to one or more Systems took longer than 100 ms. System 127.0.0.1 could be reached on port 8080. The request took 75 ms. The warning threshold for the response time is: 50 ms 128 als Wert da Ampelauswertung |
|
ERROR | 255 | The Request to one or more Systems took longer than 100 ms. System 127.0.0.1 could be reached on port 8080. The request took 2500 ms. The error threshold for the response time is: 100 ms. | |
OKAY | 0 | All B2B Systems checked are available in the given response times. | |
SYSERROR | |||
ERROR | ERROR in B2B-Customizing, there is missing an entry SYSERROR.errorThreshold=MAXVALUE in EXTERNAL_MONITORING Extension | ||
ERROR | Error reading SystemErrors from Database | ||
ERROR | ERROR in B2B-Customizing, there is missing an entry INDEXCOM.indexTableMaxEntries=MAXVALUE in EXTERNAL_MONITORING Extension | ||
OKAY | In the last 60 minutes 0 Systemerrors occured | ||
ERROR | In the last 60 minutes 206 Systemerrors occured, Error threshold 0 was reached. | ||
CCMISYNC | |||
ERROR | 255 | CCM IndexSync table is over critical threashold of 500 | |
WARN | 50 | CCM IndexSync table is over warn threashold of 100 | |
OKAY | 0 | CCM IndexSync table does not exceed warn threashold of 100 |
Technische Umsetzung der HealthChecks
-
Einträge in Systemfehlertabelle überwachen (SYSERROR)
- Auslesen aus der Datenbank mittels JDBC.
-
Ping mit Antwortzeit auf Clusterinstanzen (Ampelauswertung) (SYSAVAIL)
- Aufbau einer SocketConnection zu dem Zielsystem unter Verwendung der Portnummer. Nur wenn B2BBP auf dem Port läuft kann eine Verbindung hergestellt werden.
-
Füllgrad der INDEX und QUEUE Tabelle überwachen (INDEXCOM, CCMISYNC bzw. QUEUECOM)
- Auslesen aus der Datenbank mittels JDBC.
-
Anzahl der Verarbeitungsfehler in den letzten xx min überwachen (Ampel aufgrund von Schwellwerten) (PROCERR)
- Auslesen aus der Datenbank mittels JDBC.
-
Aktivität der aktiven Services (Mailcrawler, QueueService) überwachen (ASERVICE)
- Hinzufügen eine Registrys, das sich die Aktivitäten der Services merkt wenn der entsprechende Service versucht ein Datenbank Lock in der Klasse ApplicationLock zu bekommen. Dies wird auf jedem Clusternode ausgeführt und von der zentralen Webapplikation überwacht.
Erweiterbarkeit
Die Komponenten sind erweiterbar. Will man eine neue Komponente hinzufügen, muss hierzu eine Java-Klasse geschrieben werden, welche das Interface ITestableComponent implementiert.
Um eine weiter Komponente zu testen muss wie folgt vorgegangen werden:
- Java Komponente schreiben die das Interface: org.b2bbp.external.monitoring.components. ITestableComponent implementiert.
- Ins org.b2bbp.external.monitoring.components Packet einchecken
- B2B ExternalMonitor war neu bauen und deployen
- EXTERNAL_MONITORING Extension anpassen, damit die neue Komponente geladen wird.
class=<Alias>|<package.Classname>
. Beispiel:class=ASERVICE|org.b2bbp.external.monitoring.components.ActiveServiceComponent
Wichtig: der Alias darf nur 8 Zeichen lang sein.
Troubleshooting
Bei Timeout-Fehlern ist zu beachten, dass das Ermitteln des Status der einzelnen B2B by Practice Cluster-Instanzen synchron erfolgt. D.h., die höchste Antwortzeit einer Instanz bestimmt die Gesamtantwortzeit der External Monitoring Webapplikation. Dies betrifft vor allem die ASERVICE Komponente.
View Me Edit Me