Monitoring

Edge for Private Cloud v4.18.05

In diesem Dokument werden die Monitoring-Methoden für Komponenten beschrieben, die von einer On-Premise-Bereitstellung von Apigee Edge unterstützt werden.

Übersicht

Edge bietet mehrere Möglichkeiten, Details zu Diensten abzurufen und ihren Status zu prüfen. In der folgenden Tabelle sind die Arten von Prüfungen aufgeführt, die Sie für jeden unterstützten Dienst ausführen können:

JMX- und Management API-Monitoring-Ports

Jede Komponente unterstützt JMX- und Management API-Überwachungsaufrufe an verschiedenen Ports. In der folgenden Tabelle sind die JMX- und Management API-Ports für jeden Servertyp aufgeführt:

JMX verwenden

Für die Überwachung des Verwaltungsservers, des Nachrichten-Prozessors, von Qpid und Postgres wird JMX verwendet. JMX ist jedoch standardmäßig nur für Cassandra und standardmäßig für alle anderen Edge-Komponenten deaktiviert. Sie müssen JMX daher für jede Komponente einzeln aktivieren, bevor Sie sie überwachen können.

Die JMX-Authentifizierung ist standardmäßig nicht aktiviert. Sie können die JMX-Authentifizierung für alle Komponenten außer Cassandra aktivieren.

JMX aktivieren

JMX ist standardmäßig nur für Cassandra und standardmäßig für alle anderen Edge-Komponenten deaktiviert. In diesem Abschnitt wird beschrieben, wie Sie JMX für die anderen Edge-Komponenten aktivieren.

So aktivieren Sie JMX:

1. Bearbeiten Sie die Konfigurationsdatei der Komponente. Diese Datei befindet sich unter opt/apigee/edge-component_name/bin/start. In Produktionsumgebungen befinden sich diese Konfigurationsdateien auf verschiedenen Maschinen.

   Wählen Sie auf jedem Server einen der folgenden Dateispeicherorte aus:

   • Verwaltungsserver: /opt/apigee/edge-management-server/bin/start
   • Nachrichtenverarbeiter: /opt/apigee/edge-message-processor/bin/start
   • Postgres: /opt/apigee/edge-postgres-server/bin/start
   • Qpid: /opt/apigee/edge-qpid-server/bin/start
   • Router: /opt/apigee/edge-router/bin/start

   Angenommen, die Konfigurationsdatei des Verwaltungsservers befindet sich auf dem Server unter /opt/apigee/edge-management-server/bin/start.

2. Fügen Sie der Zeile exec, mit der die Komponente beginnt, die folgenden com.sun.management.jmxremote-Optionen hinzu:

   -Dcom.sun.management.jmxremote \
     -Dcom.sun.management.jmxremote.port=port_number \
     -Dcom.sun.management.jmxremote.local.only=false \
     -Dcom.sun.management.jmxremote.authenticate=false \
     -Dcom.sun.management.jmxremote.ssl=false

   Dabei ist port_number der JMX-Port für den Dienst. Informationen zur JMX-Portnummer Ihres Dienstes finden Sie unter JMX- und Management API-Monitoring-Ports.

   Wenn Sie beispielsweise JMX auf dem Verwaltungsserver aktivieren möchten, fügen Sie der Konfigurationsdatei des Verwaltungsservers Folgendes hinzu:

   exec $JAVA -classpath "$classpath" -Xms$min_mem -Xmx$max_mem $xx_opts \
     -Djava.security.auth.login.config=$conf_path/jaas.config \
     -Dinstallation.dir=$install_dir $sys_props -Dconf.dir=$conf_path \
     -Ddata.dir=$data_dir \
     -Dcom.sun.management.jmxremote \
     -Dcom.sun.management.jmxremote.port=1099 \
     -Dcom.sun.management.jmxremote.local.only=false \
     -Dcom.sun.management.jmxremote.authenticate=false \
     -Dcom.sun.management.jmxremote.ssl=false \
     $* $debug_options com.apigee.kernel.MicroKernel

   In diesem Beispiel wird Port 1099 für den Verwaltungsserver angegeben. Wie bereits erwähnt, hat jeder Dienst eine eigene Portnummer.

   Die bearbeitete Zeile in der Konfigurationsdatei sieht so aus:

   exec $JAVA -classpath "$classpath" -Xms$min_mem -Xmx$max_mem $xx_opts -Djava.security.auth.login.config=$conf_path/jaas.config -Dinstallation.dir=$install_dir $sys_props -Dconf.dir=$conf_path -Ddata.dir=$data_dir -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=1099 -Dcom.sun.management.jmxremote.local.only=false -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false $* $debug_options com.apigee.kernel.MicroKernel

3. Speichern Sie die Konfigurationsdatei.
4. Starten Sie die Komponente mit dem Befehl restart neu.

   Führen Sie beispielsweise den folgenden Befehl aus, um den Verwaltungsserver neu zu starten:

   /opt/apigee/apigee-service/bin/apigee-service edge-management-server restart

Die Authentifizierung für JMX ist standardmäßig nicht aktiviert. Sie können die JMX-Authentifizierung für alle Komponenten außer Cassandra aktivieren, wie unter JMX-Authentifizierung aktivieren beschrieben.

JMX-Authentifizierung aktivieren

Die JMX-Authentifizierung ist nicht standardmäßig aktiviert. Sie können die JMX-Authentifizierung für alle Komponenten außer Cassandra aktivieren.

Führen Sie die folgende change_jmx_auth-Aktion auf allen Knoten aus, um die JMX-Authentifizierung zu aktivieren:

/opt/apigee/apigee-service/bin/apigee-service component change_jmx_auth [options|-f config_file]

Wobei:

• component ist einer der folgenden Werte:
  • edge-management-server
  • edge-message-processor
  • edge-postgres-server
  • edge-qpid-server
  • edge-router
• options gibt Folgendes an:
  • -u username
  • -p password
  • -e [y|n] (aktivieren oder deaktivieren)
• Mit config_file wird der Speicherort einer Konfigurationsdatei angegeben, in der Folgendes definiert wird:
  • JMX_USERNAME=username
  • JMX_ENABLED=y|n
  • JMX_PASSWORD=password (wenn nicht festgelegt oder nicht mit -p übergeben, werden Sie aufgefordert)

Sie können entweder die Befehlszeilenoptionen oder die Konfigurationsdatei verwenden, um den Nutzernamen, das Passwort und den Aktivierungs-/Deaktivierungsstatus zu definieren. Sie geben nicht sowohl eine Reihe von Optionen als auch eine Konfigurationsdatei an.

Im folgenden Beispiel wird die JMX-Authentifizierung für den Verwaltungsserver mithilfe der Befehlszeilenoptionen aktiviert:

/opt/apigee/apigee-service/bin/apigee-service edge-management-server
    change_jmx_auth -u foo -p bar -e y

Im folgenden Beispiel wird anstelle von Befehlszeilenoptionen eine Konfigurationsdatei verwendet:

/opt/apigee/apigee-service/bin/apigee-service edge-management-server
    change_jmx_auth -f /tmp/my-config-file

Wenn Sie Edge auf mehreren Knoten ausführen, führen Sie den Befehl auf allen Knoten aus und geben Sie dabei denselben Nutzernamen und dasselbe Passwort an.

Verwenden Sie die Option „-e n“, um die JMX-Authentifizierung in der Befehlszeile zu deaktivieren, wie im folgenden Beispiel gezeigt:

/opt/apigee/apigee-service/bin/apigee-service edge-management-server
    change_jmx_auth -e n

Mit JConsole überwachen

Verwenden Sie JConsole (ein JMX-kompatibles Tool), um Systemdiagnosen und Prozessstatistiken zu verwalten und zu überwachen. Mit JConsole können Sie von Ihren Servern bereitgestellte JMX-Statistiken auf einer grafischen Benutzeroberfläche anzeigen. Weitere Informationen finden Sie unter JConsole verwenden.

Die JConsole verwendet die folgende Dienst-URL, um die über JMX angebotenen JMX-Attribute (MBeans) zu überwachen:

service:jmx:rmi:///jndi/rmi://IP_address:port_number/jmxrmi

Wobei:

• IP_address ist die IP-Adresse des Servers, den Sie überwachen möchten.
• port_number ist die JMX-Portnummer des Servers, den Sie überwachen möchten.

Wenn Sie beispielsweise den Verwaltungsserver überwachen möchten, führen Sie einen Befehl wie den folgenden aus (vorausgesetzt, die IP-Adresse des Servers lautet 216.3.128.12):

service:jmx:rmi:///jndi/rmi://216.3.128.12:1099/jmxrmi

In diesem Beispiel wird Port 1099 angegeben, der JMX-Port des Verwaltungsservers. Informationen zu anderen Ports finden Sie unter JMX- und Management API-Monitoring-Ports.

Die folgende Tabelle zeigt die generischen JMX-Statistiken:

Mit der Management API im Blick behalten

Edge enthält mehrere APIs, mit denen Sie Dienstprüfungen auf Ihren Servern sowie auf Ihre Nutzer, Organisationen und Bereitstellungen durchführen können. In diesem Abschnitt werden diese APIs beschrieben.

Dienstprüfungen durchführen

Die Verwaltungs-API bietet mehrere Endpunkte zum Überwachen und Diagnostizieren von Problemen mit Ihren Diensten. Zu diesen Endpunkten gehören:

<ServerField>
  <Up>true</Up>
</ServerField>

curl: Failed connect to localhost:port_number; Connection refused

Wenn Sie diese Endpunkte verwenden möchten, rufen Sie ein Dienstprogramm wie curl mit Befehlen mit der folgenden Syntax auf:

curl http://host:port_number/v1/servers/self/up
  -H "Accept: [application/json|application/xml]"
curl http://host:port_number/v1/servers/self -u username:password
  -H "Accept: [application/json|application/xml]"

Wobei:

• host ist die IP-Adresse des Servers, den Sie prüfen möchten. Wenn Sie auf dem Server angemeldet sind, können Sie „localhost“ verwenden. Andernfalls geben Sie die IP-Adresse des Servers sowie den Nutzernamen und das Passwort an.
• port_number ist der Management API-Port für den Server, den Sie prüfen möchten. Dieser Anschluss ist für jeden Komponententyp unterschiedlich. Beispiel: Der Management API-Port des Verwaltungsservers ist 8080. Eine Liste der zu verwendenden Management API-Portnummern finden Sie unter JMX- und Management API-Monitoring-Ports.

Wenn Sie das Format der Antwort ändern möchten, können Sie den Accept-Header als „application/json“ oder „application/xml“ angeben.

Im folgenden Beispiel wird der Status des Routers auf dem lokalen Host (Port 8081) abgerufen:

curl http://localhost:8081/v1/servers/self/up -H "Accept: application/xml"

Im folgenden Beispiel werden Informationen zum Message Processor unter 216.3.128.12 (Port 8082) abgerufen:

curl http://216.3.128.12:8082/v1/servers/self -u sysAdminEmail:password
  -H "Accept: application/xml"

Nutzer-, Organisations- und Bereitstellungsstatus im Blick behalten

Mit der Management API können Sie den Nutzer-, Organisations- und Bereitstellungsstatus Ihrer Proxys auf Management-Servern und Nachrichten-Prozessoren überwachen. Dazu geben Sie die folgenden Befehle ein:

curl http://host:port_number/v1/users -u sysAdminEmail:password
curl http://host:port_number/v1/organizations -u sysAdminEmail:password
curl http://host:port_number/v1/organizations/orgname/deployments -u sysAdminEmail:password

Dabei ist port_number entweder 8080 für den Verwaltungsserver oder 8082 für den Message Processor.

Für diesen Aufruf müssen Sie sich mit Ihrem Nutzernamen und Passwort für die Systemadministration authentifizieren.

Der Server sollte für alle Aufrufe den Status „deployed“ zurückgeben. Wenn diese Schritte nicht funktionieren, gehen Sie so vor:

1. Prüfen Sie die Serverprotokolle auf Fehler. Die Protokolle befinden sich hier:
   • Verwaltungsserver: opt/apigee/var/log/edge-management-server
   • Nachrichtenprozessor: opt/apigee/var/log/edge-message-processor
2. Rufen Sie den Server auf, um zu prüfen, ob er richtig funktioniert.
3. Entfernen Sie den Server aus dem ELB und starten Sie ihn dann neu:

   /opt/apigee/apigee-service/bin/apigee-service service_name restart

   Wo service_name Folgendes ist:

   • edge-management-server
   • edge-message-processor

Status mit dem Befehl apigee-service prüfen

Sie können Ihre Edge-Dienste mit dem Befehl apigee-service beheben, wenn Sie auf dem Server, auf dem der Dienst ausgeführt wird, angemeldet sind.

So prüfen Sie den Status eines Dienstes mit apigee-service:

1. Melden Sie sich beim Server an und führen Sie den folgenden Befehl aus:

   /opt/apigee/apigee-service/bin/apigee-service service_name status

   Dabei kann service_name für folgendes stehen:

   • Verwaltungsserver: edge-management-server
   • Nachrichtenprozessor: edge-message-processor
   • Postgres: edge-postgres-server
   • QPID: edge-qpid-server
   • Router: edge-router

   Beispiel:

   /opt/apigee/apigee-service/bin/apigee-service edge-message-processor status

2. Wenn der Dienst nicht ausgeführt wird, starten Sie ihn:

   /opt/apigee/apigee-service/bin/apigee-service service_name start

3. Prüfen Sie nach dem Neustart des Dienstes, ob er funktioniert. Verwenden Sie dazu entweder den Befehl apigee-service status, den Sie zuvor verwendet haben, oder die Management API, die unter Mit der Management API überwachen beschrieben wird.

   Beispiel:

   curl -v http://localhost:port_number/v1/servers/self/up

   Dabei ist port_number der Management API-Port für den Dienst.

   In diesem Beispiel wird davon ausgegangen, dass Sie auf dem Server angemeldet sind und „localhost“ als Hostnamen verwenden können. Wenn Sie den Status per Fernzugriff mit der Management API prüfen möchten, müssen Sie die IP-Adresse des Servers angeben und den Nutzernamen und das Passwort des Systemadministrators in Ihren API-Aufruf aufnehmen.

Postgres-Monitoring

Postgres unterstützt mehrere Dienstprogramme, mit denen Sie den Status prüfen können. Diese Dienstprogramme werden in den folgenden Abschnitten beschrieben.

Organisationen und Umgebungen in Postgres prüfen

Sie können mit dem folgenden curl-Befehl nach Namen von Organisationen und Umgebungen suchen, die auf dem Postgres-Server eingerichtet sind:

curl -v http://postgres_IP:8084/v1/servers/self/organizations

Im System sollten der Organisations- und der Umgebungsname angezeigt werden.

Analysestatus überprüfen

Sie können den Status der Postgres- und Qpid-Analyseserver mit dem folgenden curl-Befehl prüfen:

curl -u userEmail:password http://host:port_number/v1/organizations/orgname/environments/envname/provisioning/axstatus

Das System sollte für alle Analyseserver einen Erfolgsstatus anzeigen, wie im folgenden Beispiel gezeigt:

{
  "environments" : [ {
    "components" : [ {
      "message" : "success at Thu Feb 28 10:27:38 CET 2013",
      "name" : "pg",
      "status" : "SUCCESS",
      "uuid" : "[c678d16c-7990-4a5a-ae19-a99f925fcb93]"
     }, {
      "message" : "success at Thu Feb 28 10:29:03 CET 2013",
      "name" : "qs",
      "status" : "SUCCESS",
      "uuid" : "[ee9f0db7-a9d3-4d21-96c5-1a15b0bf0adf]"
     } ],
    "message" : "",
    "name" : "prod"
   } ],
  "organization" : "acme",
  "status" : "SUCCESS"
}

PostgreSQL-Datenbank

In diesem Abschnitt werden Methoden beschrieben, die Sie speziell für die Überwachung der PostgreSQL-Datenbank verwenden können.

check_postgres.pl-Script verwenden

Sie können ein Standard-Monitoring-Script verwenden, um die PostgreSQL-Datenbank zu überwachen: check_postgres.pl. Weitere Informationen finden Sie unter http://bucardo.org/wiki/Check_postgres.

Vor dem Ausführen des Scripts:

1. Sie müssen das Script „check_postgres.pl“ auf jedem Postgres-Knoten installieren.
2. Sie müssen perl-Time-HiRes.x86_64 installiert haben, ein Perl-Modul, das Wecker, Sleep, gettimeofday und Intervall-Timer mit hoher Auflösung implementiert. Sie können es beispielsweise mit dem folgenden Befehl installieren:
   

   yum install perl-Time-HiRes.x86_64

3. CentOS 7: Bevor Sie check_postgres.pl unter CentOS 7 verwenden, müssen Sie das RPM perl-Data-Dumper.x86_64 installieren.

check_postgres.pl-Ausgabe

Die Standardausgabe der API-Aufrufe mit check_postgres.pl ist mit Nagios kompatibel. Führen Sie nach der Installation des Scripts die folgenden Prüfungen durch:

1. Prüfen Sie die Datenbankgröße:

   check_postgres.pl -H 10.176.218.202 -db apigee -u apigee -dbpass postgres -include=apigee -action database_size --warning='800 GB' --critical='900 GB'

2. Prüfen Sie die Anzahl der eingehenden Verbindungen zur Datenbank und vergleichen Sie sie mit der maximal zulässigen Anzahl:

   check_postgres.pl -H 10.176.218.202 -db apigee -u apigee -dbpass postgres -action backends

3. Prüfen Sie, ob die Datenbank ausgeführt wird und verfügbar ist:

   check_postgres.pl -H 10.176.218.202 -db apigee -u apigee -dbpass postgres -action connection

4. Prüfen Sie den Speicherplatz:

   check_postgres.pl -H 10.176.218.202 -db apigee -u apigee -dbpass postgres -action disk_space --warning='80%' --critical='90%'

5. Prüfen Sie die Anzahl der Organisationen und Umgebungen, die in einem Postgres-Knoten eingerichtet wurden:

   check_postgres.pl -H 10.176.218.202 -db apigee -u apigee -dbpass postgres -action=custom_query --query="select count(*) as result from pg_tables where schemaname='analytics' and tablename like '%fact'" --warning='80' --critical='90' --valtype=integer

Datenbankprüfungen ausführen

Sie können prüfen, ob die richtigen Tabellen in der PostgreSQL-Datenbank erstellt wurden. Melden Sie sich mit dem folgenden Befehl in der PostgreSQL-Datenbank an:

psql -h /opt/apigee/var/run/apigee-postgresql/ -U apigee -d apigee

Führen Sie dann diesen Befehl aus:

\d analytics."org.env.fact"

Systemstatus des Postgres-Prozesses prüfen

Sie können API-Prüfungen auf dem Postgres-Rechner ausführen, indem Sie den folgenden curl-Befehl aufrufen:

curl -v http://postgres_IP:8084/v1/servers/self/health

Dieser Befehl gibt den Status ACTIVE zurück, wenn der Postgres-Prozess aktiv ist. Wenn der Postgres-Prozess nicht aktiv ist, wird der Status INACTIVE zurückgegeben.

Postgres-Ressourcen

Weitere Informationen zum Überwachen des Postgres-Dienstes finden Sie hier:

• http://www.postgresql.org/docs/9.0/static/monitoring.html
• http://www.postgresql.org/docs/9.0/static/diskusage.html
• http://bucardo.org/check_postgres/check_postgres.pl.html

Apache Cassandra

JConsole verwenden: Aufgabenstatistiken überwachen

Verwenden Sie JConsole und die folgende Dienst-URL, um die über JMX angebotenen JMX-Attribute (MBeans) zu überwachen:

service:jmx:rmi:///jndi/rmi://IP_address:7199/jmxrmi

Dabei ist IP_address die IP-Adresse des Cassandra-Servers.

JMX ist für Cassandra standardmäßig aktiviert und für den Remote-JMX-Zugriff auf Cassandra ist kein Passwort erforderlich.

Cassandra-JMX-Statistiken

Clusterknoten mit nodetool verwalten

Das nodetool-Dienstprogramm ist eine Befehlszeile für Cassandra, die Clusterknoten verwaltet. Sie finden das Dienstprogramm unter /opt/apigee/apigee-cassandra/bin.

Die folgenden Aufrufe können auf allen Cassandra-Clusterknoten ausgeführt werden:

1. Allgemeine Ringinformationen (auch für einen einzelnen Cassandra-Knoten möglich): Prüfen Sie, ob für alle Knoten der Status „Up“ (Aktiv) und „Normal“ angezeigt wird.

   nodetool -h localhost ring

   Die Ausgabe des Befehls sieht in etwa so aus:

   Datacenter: dc-1
   ==========
   Address            Rack     Status State   Load    Owns    Token
   192.168.124.201    ra1      Up     Normal  1.67 MB 33,33%  0
   192.168.124.202    ra1      Up     Normal  1.68 MB 33,33%  5671...5242
   192.168.124.203    ra1      Up     Normal  1.67 MB 33,33%  1134...0484

2. Allgemeine Informationen zu Knoten (Anruf pro Knoten)

   nodetool -h localhost info

   Die Ausgabe des Befehls sieht in etwa so aus:

   ID                     : e2e42793-4242-4e82-bcf0-oicu812
   Gossip active          : true
   Thrift active          : true
   Native Transport active: true
   Load                   : 273.71 KB
   Generation No          : 1234567890
   Uptime (seconds)       : 687194
   Heap Memory (MB)       : 314.62 / 3680.00
   Off Heap Memory (MB)   : 0.14
   Data Center            : dc-1
   Rack                   : ra-1
   Exceptions             : 0
   Key Cache              : entries 150, size 13.52 KB, capacity 100 MB, 1520781 hits, 1520923 requests, 1.000 recent hit rate, 14400 save period in seconds
   Row Cache              : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0 requests, NaN recent hit rate, 0 save period in seconds
   Counter Cache          : entries 0, size 0 bytes, capacity 50 MB, 0 hits, 0 requests, NaN recent hit rate, 7200 save period in seconds
   Token                  : 0

3. Status des Thrift-Servers (für die Client-API)

   nodetool -h localhost statusthrift

   Die Ausgabe des Befehls sieht in etwa so aus:
   

   running

4. Status von Datenstreamingvorgängen: Beobachten Sie den Traffic für Cassandra-Knoten:

   nodetool -h localhost netstats

   Die Ausgabe des Befehls sieht in etwa so aus:
   

   Mode: NORMAL
   Not sending any streams.
   Read Repair Statistics:
   Attempted: 151612
   Mismatch (Blocking): 0
   Mismatch (Background): 0
   Pool Name                    Active   Pending      Completed   Dropped
   Commands                        n/a         0              0         0
   Responses                       n/a         0              0       n/a

Weitere Informationen zu nodetool finden Sie unter Das nodetool-Dienstprogramm.

Cassandra-Monitoring (Benutzeroberfläche)

Weitere Informationen finden Sie unter http://www.datastax.com/products/opscenter.

Cassandra-Ressource

Weitere Informationen finden Sie unter http://www.datastax.com/docs/1.0/operations/monitoring.

Apache ZooKeeper

ZooKeeper-Status prüfen

1. Prüfen Sie, ob der ZooKeeper-Prozess ausgeführt wird. ZooKeeper schreibt eine PID-Datei in opt/apigee/var/run/apigee-zookeeper/apigee-zookeeper.pid.
2. Testen Sie ZooKeeper-Ports, um sicherzustellen, dass Sie auf jedem ZooKeeper-Server eine TCP-Verbindung zu den Ports 2181 und 3888 herstellen können.
3. Prüfen Sie, ob Sie Werte aus der ZooKeeper-Datenbank lesen können. Stellen Sie eine Verbindung über eine ZooKeeper-Clientbibliothek (oder /opt/apigee/apigee-zookeeper/bin/zkCli.sh) her und lesen Sie einen Wert aus der Datenbank.
4. Prüfen Sie den Status:

   /opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper status

Vierstellige ZooKeeper-Wörter verwenden

ZooKeeper kann über eine kleine Anzahl von Befehlen (Vier-Buchstaben-Wörter) überwacht werden, die über Netcat (nc) oder Telnet an den Port 2181 gesendet werden.

Weitere Informationen zu ZooKeeper-Befehlen finden Sie in der Referenz zu Apache ZooKeeper-Befehlen.

Beispiel:

• srvr: Hier werden alle Details zum Server aufgeführt.
• stat: Hier werden kurze Details zum Server und zu den verbundenen Clients aufgeführt.

Die folgenden Befehle können an den ZooKeeper-Port gesendet werden:

1. Führen Sie den aus vier Buchstaben bestehenden Befehl „ruok“ aus, um zu testen, ob der Server fehlerfrei ausgeführt wird. Eine erfolgreiche Antwort gibt „imok“ zurück.

   echo ruok | nc host 2181

   Liefert:

   imok

2. Führen Sie den vierstelligen Befehl stat aus, um Statistiken zur Serverleistung und zu verbundenen Clients aufzulisten:

   echo stat | nc host 2181

   Liefert:

   Zookeeper version: 3.4.5-1392090, built on 09/30/2012 17:52 GMT
   Clients:
   /0:0:0:0:0:0:0:1:33467[0](queued=0,recved=1,sent=0)
   /192.168.124.201:42388[1](queued=0,recved=8433,sent=8433)
   /192.168.124.202:42185[1](queued=0,recved=1339,sent=1347)
   /192.168.124.204:39296[1](queued=0,recved=7688,sent=7692)
   Latency min/avg/max: 0/0/128
   Received: 26144
   Sent: 26160
   Connections: 4
   Outstanding: 0
   Zxid: 0x2000002c2
   Mode: follower
   Node count: 283

3. Wenn netcat (nc) nicht verfügbar ist, können Sie Python als Alternative verwenden. Erstellen Sie eine Datei mit dem Namen zookeeper.py, die Folgendes enthält:

   import time, socket,
   sys c = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
   c.connect((sys.argv[1], 2181))
   c.send(sys.argv[2])
   time.sleep(0.1)
   print c.recv(512)

   Führen Sie nun die folgenden Python-Zeilen aus:

   python zookeeper.py 192.168.124.201 ruok
   python zookeeper.py 192.168.124.201 stat

Test auf LDAP-Ebene

Sie können OpenLDAP überwachen, um zu sehen, ob die jeweiligen Anfragen ordnungsgemäß ausgeführt werden. Mit anderen Worten: Suchen Sie nach einer bestimmten Suche, die das richtige Ergebnis zurückgibt.

1. Verwenden Sie ldapsearch (yum install openldap-clients), um den Eintrag des Systemadministrators abzufragen. Mit diesem Eintrag werden alle API-Aufrufe authentifiziert.

   ldapsearch -b "uid=admin,ou=users,ou=global,dc=apigee,dc=com" -x -W -D "cn=manager,dc=apigee,dc=com" -H ldap://localhost:10389 -LLL

   Sie werden dann aufgefordert, das LDAP-Administratorpasswort einzugeben:

   Enter LDAP Password:

   Nachdem Sie das Passwort eingegeben haben, wird eine Antwort im Formular angezeigt:

   dn:
   uid=admin,ou=users,ou=global,dc=apigee,dc=com
   objectClass: organizationalPerson
   objectClass: person
   objectClass: inetOrgPerson
   objectClass: top
   uid: admin
   cn: admin
   sn: admin
   userPassword:: e1NTSEF9bS9xbS9RbVNXSFFtUWVsU1F0c3BGL3BQMkhObFp2eDFKUytmZVE9PQ=
    =
   mail: opdk@google.com

2. Prüfen Sie mit dem folgenden Befehl, ob der Verwaltungsserver noch mit dem LDAP verbunden ist:

   curl -u userEMail:password http://localhost:8080/v1/users/ADMIN

   Liefert:

   {
     "emailId" : ADMIN,
     "firstName" : "admin",
     "lastName" : "admin"
   }

Sie können auch die OpenLDAP-Caches überwachen, um die Anzahl der Festplattenzugriffe zu reduzieren und so die Leistung des Systems zu verbessern. Das Monitoring und die anschließende Optimierung der Cache-Größe auf dem OpenLDAP-Server kann die Leistung des Verzeichnisservers erheblich beeinträchtigen. In den Protokolldateien (opt/apigee/var/log) finden Sie Informationen zum Cache.