Diese Seite wurde von der Cloud Translation API übersetzt.

Monitoring

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 zulässigen Dienst ausführen können:

		Mgmt API
Dienst	Arbeitsspeichernutzung [JMX^*]	Dienstüberprüfung	Nutzer-/Organisations-/Bereitstellungsstatus	axstatus	Datenbankprüfung	`apigee-service`-Status	`apigee-monit`**
Verwaltungsserver
Message Processor
Postgres
Qpid
Router
	Weitere Informationen	Weitere Informationen	Weitere Informationen	Weitere Informationen	Weitere Informationen	Weitere Informationen	Weitere Informationen
^{* Bevor Sie JMX verwenden können, müssen Sie es wie unter JMX aktivieren beschrieben aktivieren.} ^{** Der apigee-monit-Dienst prüft, ob eine Komponente aktiv ist. Ist dies nicht der Fall, versucht der Dienst, sie neu zu starten. Weitere Informationen finden Sie unter Selbstheilung mit apigee-monit.}

JMX- und Management API-Monitoring-Ports

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

Komponente	JMX-Port	Management API-Port
Verwaltungsserver	1099	8080
Router	1100	8081
Message Processor	1101	8082
Qpid	1102	8083
Postgres	1103	8084

JMX für Monitoring 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 aktiviert und für alle anderen Edge-Komponenten standardmäßig 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 aktivieren. Folgen Sie für Cassandra der Anleitung unter JMX-Authentifizierung für 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.

Hinweis: HINWEIS: Wir empfehlen, nach der Konfiguration von JMX die Datei /opt/apigee/<component>/bin/start zu sichern. Diese Datei bleibt zwischen Patchupgrades nicht erhalten und muss aus einer Sicherung wiederhergestellt werden.

So aktivieren Sie JMX:

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 Speicherorte für Dateien aus:
- Verwaltungsserver: /opt/apigee/edge-management-server/bin/start
- Nachrichtenprozessor: /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
Die Konfigurationsdatei des Verwaltungsservers befindet sich beispielsweise auf dem Server unter /opt/apigee/edge-management-server/bin/start.

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 dann 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

Speichern Sie die Konfigurationsdatei.
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 aktivieren, wie unter JMX-Authentifizierung aktivieren beschrieben. Informationen zum Aktivieren der JMX-Authentifizierung für Cassandra finden Sie unter JMX-Authentifizierung für Cassandra aktivieren.

JMX-Authentifizierung aktivieren

Die JMX-Authentifizierung ist nicht standardmäßig aktiviert. Sie können die JMX-Authentifizierung für alle Komponenten aktivieren. Für Cassandra folgen Sie der Anleitung unter JMX-Authentifizierung für 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_name 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 einen Satz 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.

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, geben Sie einen Befehl wie den folgenden ein (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 ist Port 1099 angegeben. Das ist der JMX-Port des Verwaltungsservers. Informationen zu anderen Ports finden Sie unter Monitoring-Ports für JMX und Management API.

In der folgenden Tabelle sind die allgemeinen JMX-Statistiken aufgeführt:

JMX-MBeans	JMX-Attribute
Speicher	HeapMemoryUsage
	NonHeapMemoryUsage
	Nutzung
HINWEIS Attributwerte werden in vier Werten angezeigt: "committ", " init", "max" und "used".

Mit der Verwaltungs-API überwachen

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 Management API bietet mehrere Endpunkte für das Monitoring und die Diagnose von Problemen mit Ihren Diensten. Zu diesen Endpunkten gehören:

Endpunkt Beschreibung

Endpunkt	Beschreibung
`/servers/self/up`	Prüft, ob ein Dienst ausgeführt wird. Für diesen API-Aufruf ist keine Authentifizierung erforderlich. Wenn der Dienst ausgeführt wird, gibt dieser Endpunkt die folgende Antwort zurück: <ServerField> <Up>true</Up> </ServerField> Wenn der Dienst nicht ausgeführt wird, erhalten Sie je nach Dienst und Art der Prüfung eine Antwort, die in etwa so aussieht: curl: Failed connect to localhost:`port_number`; Connection refused
`/servers/self`	Gibt Informationen zum Dienst zurück, darunter: Konfigurationsattribute Startzeit und Startzeit Build-, RPM- und UUID-Informationen Interner und externer Hostname und IP-Adresse Region und Pod `<isUp>`-Attribut, das angibt, ob der Dienst ausgeführt wird Für diesen API-Aufruf müssen Sie sich mit Ihren Apigee-Administratoranmeldedaten authentifizieren.

/servers/self/up

Prüft, ob ein Dienst ausgeführt wird. Für diesen API-Aufruf ist keine Authentifizierung erforderlich.

Wenn der Dienst ausgeführt wird, gibt dieser Endpunkt die folgende Antwort zurück:

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

Wenn der Dienst nicht ausgeführt wird, erhalten Sie je nach Dienst und Art der Prüfung eine Antwort, die in etwa so aussieht:

curl: Failed connect to localhost:port_number; Connection refused

/servers/self

Gibt Informationen zum Dienst zurück, darunter:

Konfigurationsattribute
Startzeit und Startzeit
Build-, RPM- und UUID-Informationen
Interner und externer Hostname und IP-Adresse
Region und Pod
<isUp>-Attribut, das angibt, ob der Dienst ausgeführt wird

Für diesen API-Aufruf müssen Sie sich mit Ihren Apigee-Administratoranmeldedaten authentifizieren.

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 beim Server angemeldet sind, können Sie „localhost“ verwenden. Geben Sie andernfalls 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:

Prüfen Sie die Serverprotokolle auf Fehler. Die Logs finden Sie unter:
- Verwaltungsserver: opt/apigee/var/log/edge-management-server
- Nachrichtenprozessor: opt/apigee/var/log/edge-message-processor
Rufen Sie den Server auf, um zu prüfen, ob er richtig funktioniert.
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 Fehler in Ihren Edge-Diensten mit dem Befehl apigee-service beheben, wenn Sie bei dem Server angemeldet sind, auf dem der Dienst ausgeführt wird.

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

Melden Sie sich auf dem 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
```

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

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

Prüfen Sie nach dem Neustart des Dienstes, ob er funktioniert. Verwenden Sie dazu entweder den zuvor verwendeten apigee-service status-Befehl oder die Management API (siehe Mit der Management API überwachen).
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 seinen 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

Das System sollte den Namen der Organisation und der Umgebung anzeigen.

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 zu sehen:

{
  "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 Techniken beschrieben, die Sie speziell für das Monitoring der Postgres-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:

Sie müssen das Script „check_postgres.pl“ auf jedem Postgres-Knoten installieren.
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
```
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:

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'

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
```

Prüfen, 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

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%'

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:

Apache Cassandra

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

JMX-Authentifizierung für Cassandra aktivieren

Sie können die JMX-Authentifizierung für Cassandra aktivieren. Danach müssen Sie bei allen Aufrufen des nodetool-Dienstprogramms einen Nutzernamen und ein Passwort angeben.

So aktivieren Sie die JMX-Authentifizierung für Cassandra:

Erstellen und bearbeiten Sie die Datei cassandra.properties:
1. Bearbeiten Sie die Datei /opt/apigee/customer/application/cassandra.properties. Wenn die Datei nicht vorhanden ist, erstellen Sie sie.
2. Fügen Sie der Datei Folgendes hinzu:
```
conf_cassandra-env_com.sun.management.jmxremote.authenticate=true
conf_cassandra-env_com.sun.management.jmxremote.password.file=${APIGEE_ROOT}/data/apigee-cassandra/jmxremote.password
conf_cassandra-env_com.sun.management.jmxremote.access.file=${APIGEE_ROOT}/data/apigee-cassandra/jmxremote.access
```
3. Speichern Sie die Datei cassandra.properties.
4. Ändern Sie den Eigentümer der Datei in apigee:apigee, wie im folgenden Beispiel gezeigt:
```
chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
```
Weitere Informationen zur Verwendung von Eigenschaftsdateien zum Festlegen von Tokens finden Sie unter So konfigurieren Sie Edge.
So erstellen und bearbeiten Sie jmx_auth.sh:
1. Erstellen Sie eine Datei an folgendem Speicherort, falls sie noch nicht vorhanden ist:
```
/opt/apigee/customer/application/jmx_auth.sh
```
2. Fügen Sie der Datei die folgenden Properties hinzu:
```
export CASS_JMX_USERNAME=JMX_USERNAME
export CASS_JMX_PASSWORD=JMX_PASSWORD
```
3. Speichern Sie die Datei jmx_auth.sh.
4. Quelldatei angeben:
```
source /opt/apigee/customer/application/jmx_auth.sh
```
Kopieren und bearbeiten Sie die Datei jmxremote.password:
1. Kopieren Sie die folgende Datei aus dem Verzeichnis $JAVA_HOME in /opt/apigee/data/apigee-cassandra/:
```
cp ${JAVA_HOME}/lib/management/jmxremote.password.template $APIGEE_ROOT/data/apigee-cassandra/jmxremote.password
```
2. Bearbeiten Sie die Datei jmxremote.password und fügen Sie Ihren JMX-Nutzernamen und Ihr JMX-Passwort mit der folgenden Syntax hinzu:
```
JMX_USERNAME JMX_PASSWORD
```
  Dabei sind JMX_USERNAME und JMX_PASSWORD der zuvor festgelegte JMX-Nutzername und das zuvor festgelegte JMX-Passwort.
3. Die Datei muss zu „apigee“ gehören und der Dateimodus muss 400 sein:
```
chown apigee:apigee /opt/apigee/data/apigee-cassandra/jmxremote.password
chmod 400 /opt/apigee/data/apigee-cassandra/jmxremote.password
```
Kopieren und bearbeiten Sie die Datei jmxremote.access:
1. Kopieren Sie die folgende Datei aus dem Verzeichnis $JAVA_HOME in /opt/apigee/data/apigee-cassandra/:
```
cp ${JAVA_HOME}/lib/management/jmxremote.access $APIGEE_ROOT/data/apigee-cassandra/jmxremote.access
```
2. Bearbeiten Sie die Datei „jmxremote.access“ und fügen Sie die folgende Rolle hinzu:
```
JMX_USERNAME readwrite
```
3. Die Datei muss zu „apigee“ gehören und der Dateimodus muss 400 sein:
```
chown apigee:apigee /opt/apigee/data/apigee-cassandra/jmxremote.access
chmod 400 /opt/apigee/data/apigee-cassandra/jmxremote.access
```

Führen Sie configure unter Cassandra aus:

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra configure

Starten Sie Cassandra neu:

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra restart

Wiederholen Sie diesen Vorgang auf allen anderen Cassandra-Knoten.

JMX-Passwortverschlüsselung aktivieren

So aktivieren Sie die JMX-Passwortverschlüsselung:

Öffnen Sie die Datei source/conf/casssandra-env.sh.
Entfernen Sie die Kommentarzeichen für die folgenden Zeilen in der Datei:
- JVM_OPTS="$JVM_OPTS -Djava.security.auth.login.config={T}conf_cassandra-env_java.security.auth.login.config{/T}"
- JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.login.config=ApigeeSecureFileLoginModule"
Generieren Sie in der Befehlszeile SHA1-Hashes der gewünschten Passwörter, indem Sie echo -n 'Secret' | openssl dgst -sha1 eingeben.
Legen Sie als Passwort den Nutzernamen in jmxremote.password fest.
Ändern Sie die Datei cassandra-env.sh nach dem Update wieder in den schreibgeschützten Modus.

JMX mit SSL für Cassandra aktivieren

Wenn Sie JMX mit SSL aktivieren, erhalten Sie zusätzliche Sicherheit und Verschlüsselung für die JMX-basierte Kommunikation mit Cassandra. Wenn Sie JMX mit SSL aktivieren möchten, müssen Sie Cassandra einen Schlüssel und ein Zertifikat zur Verfügung stellen, damit SSL-basierte JMX-Verbindungen akzeptiert werden. Außerdem müssen Sie nodetool und alle anderen Tools, die über JMX mit Cassandra kommunizieren, für SSL konfigurieren.

SSL-fähige JMX-Verbindungen unterstützen sowohl unverschlüsselte als auch verschlüsselte JMX-Passwörter.

Gehen Sie folgendermaßen vor, um JMX mit SSL für Cassandra zu aktivieren:

Aktivieren Sie JMX. Aktivieren Sie gegebenenfalls die Passwortverschlüsselung.
Aktivieren Sie die JMX-Authentifizierung für Cassandra. wie oben beschrieben. Prüfen Sie, ob nodetool mit dem konfigurierten Nutzernamen und Passwort funktioniert.
```
/opt/apigee/apigee-cassandra/bin/nodetool -u <JMX_USER> -pw <JMX_PASS> ring
```
Schlüsselspeicher und Truststore vorbereiten
- Der Schlüsselspeicher sollte einen Schlüssel und ein Zertifikat enthalten und wird zum Konfigurieren des Cassandra-Servers verwendet. Wenn der Schlüsselspeicher mehrere Schlüsselpaare enthält, verwendet Cassandra das erste Schlüsselpaar, um SSL zu aktivieren.
  
  Die Passwörter für den Schlüsselspeicher und den Schlüssel müssen gleich sein (Standardeinstellung beim Generieren des Schlüssels mit keytool).
- Truststore sollte nur das Zertifikat enthalten und von Clients (Apigee-service-basierte Befehle oder Nodetool) verwendet werden, um eine Verbindung über JMX herzustellen.
Nachdem Sie die oben genannten Anforderungen überprüft haben, geschieht Folgendes:
1. Platzieren Sie die Schlüsselspeicherdatei in /opt/apigee/data/apigee-cassandra.
2. Sorgen Sie dafür, dass die Keystore-Datei nur von Apigee-Nutzern gelesen werden kann, indem Sie
```
chown apigee:apigee /opt/apigee/data/apigee-cassandra/keystore.node1
chmod 400 /opt/apigee/data/apigee-cassandra/keystore.node1
```
  eingeben.
Konfigurieren Sie Cassandra für JMX mit SSL mit den folgenden Schritten:
1. Beenden Sie den Cassandra-Knoten, indem Sie
```
apigee-service apigee-cassandra stop
```
  eingeben.
2. Aktivieren Sie SSL in Cassandra, indem Sie die Datei /opt/apigee/customer/application/cassandra.properties öffnen und die folgende Zeile hinzufügen:
```
conf_cassandra-env_com.sun.management.jmxremote.ssl=true
```
  Der Eigentümer der Datei sollte apigee:apigee sein.
3. So aktivieren Sie die SSL-Konfiguration in Cassandra: Öffnen Sie die Datei /opt/apigee/apigee-cassandra/source/conf/cassandra-env.sh und entfernen Sie die Kommentarzeichen vor den folgenden Zeilen. Ändern Sie bei Bedarf den Pfad /opt/apigee/data/apigee-cassandra/keystore.node1 und das Passwort für den Schlüsselspeicher.
```
JVM_OPTS="$JVM_OPTS -Djavax.net.ssl.keyStore=/opt/apigee/data/apigee-cassandra/keystore.node1"
JVM_OPTS="$JVM_OPTS -Djavax.net.ssl.keyStorePassword=keystore-password"
JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.registry.ssl=true"
```
  Der Eigentümer der Datei muss apigee:apigee sein.
4. Starten Sie den Cassandra-Knoten, indem Sie
```
apigee-service apigee-cassandra start
```
  eingeben.
Konfigurieren Sie die apigee-service-Cassandra-Befehle. Sie müssen bestimmte Umgebungsvariablen festlegen, während Sie apigee-service-Befehle ausführen, einschließlich der folgenden:
```
apigee-service apigee-cassandra stop
apigee-service apigee-cassandra wait_for_ready
apigee-service apigee-cassandra ring
apigee-service apigee-cassandra backup
```
Es gibt mehrere Möglichkeiten, apigee-service für die JMX-Authentifizierung und SSL zu konfigurieren. Wählen Sie eine Option basierend auf der Nutzerfreundlichkeit und Ihren Sicherheitspraktiken aus.
Option 1 (SSL-Argumente in Datei gespeichert)

Legen Sie die folgenden Umgebungsvariablen fest:
```
export CASS_JMX_USERNAME=ADMIN
# Provide encrypted password here if you have setup JMX password encryption
export CASS_JMX_PASSWORD=PASSWORD
export CASS_JMX_SSL=Y
```
Erstellen Sie eine Datei im Basisverzeichnis des Apigee-Nutzers (/opt/apigee).
```
$HOME/.cassandra/nodetool-ssl.properties
```
Bearbeiten Sie die Datei und fügen Sie die folgenden Zeilen hinzu:
```
-Djavax.net.ssl.trustStore=<path-to-truststore.node1>
-Djavax.net.ssl.trustStorePassword=<truststore-password>
-Dcom.sun.management.jmxremote.registry.ssl=true
```
Achten Sie darauf, dass die Trustore-Datei für den Apigee-Nutzer lesbar ist.

Führen Sie dazu den folgenden apigee-service-Befehl aus. Wenn er ohne Fehler ausgeführt wird, sind Ihre Konfigurationen korrekt.
```
apigee-service apigee-cassandra ring
```
Option 2 (In Umgebungsvariablen gespeicherte SSL-Argumente)

Legen Sie die folgenden Umgebungsvariablen fest:
```
export CASS_JMX_USERNAME=ADMIN
# Provide encrypted password here if you have setup JMX password encryption
export CASS_JMX_PASSWORD=PASSWORD
export CASS_JMX_SSL=Y
# Ensure the truststore file is accessible by Apigee user.
export CASS_JMX_TRUSTSTORE=<path-to-trustore.node1>
export CASS_JMX_TRUSTSTORE_PASSWORD=<truststore-password>
```
Führen Sie dazu den folgenden apigee-service-Befehl aus. Wenn er ohne Fehler ausgeführt wird, sind Ihre Konfigurationen korrekt.
```
apigee-service apigee-cassandra ring
```
Option 3 (SSL-Argumente werden direkt an apigee-service übergeben)

Führen Sie einen beliebigen apigee-service-Befehl wie den folgenden aus. Sie müssen keine Umgebungsvariablen konfigurieren.
```
CASS_JMX_USERNAME=ADMIN CASS_JMX_PASSWORD=PASSWORD CASS_JMX_SSL=Y CASS_JMX_TRUSTSTORE=<path-to-trustore.node1> CASS_JMX_TRUSTSTORE_PASSWORD=<trustore-password> /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra ring
```
Richten Sie das Nodetool ein. Nodetool erfordert, dass JMX-Parameter übergeben werden. Es gibt zwei Möglichkeiten, um Nodetool für die Ausführung mit SSL-aktiviertem JMX zu konfigurieren, wie in den folgenden Konfigurationsoptionen beschrieben:
- Konfigurationsoption 1
- Konfigurationsoption 2
Die Optionen unterscheiden sich darin, wie SSL-bezogene Konfigurationen an nodetool übergeben werden. In beiden Fällen sollte der Nutzer, der nodetool ausführt, Leseberechtigungen für die Truststore-Datei haben. Wählen Sie eine geeignete Option basierend auf der Nutzerfreundlichkeit und Ihren Sicherheitspraktiken aus.

Weitere Informationen zu den Parametern von nodetool finden Sie in der DataStax-Dokumentation.

Konfigurationsoption 1

Erstellen Sie eine Datei im Basisverzeichnis des Nutzers, der nodetool ausführt.
```
$HOME/.cassandra/nodetool-ssl.properties
```
Fügen Sie der Datei die folgenden Zeilen hinzu:
```
-Djavax.net.ssl.trustStore=<path-to-truststore.node1>
-Djavax.net.ssl.trustStorePassword=<truststore-password>
-Dcom.sun.management.jmxremote.registry.ssl=true
```
Auf den oben angegebenen Truststore-Pfad muss jeder Nutzer zugreifen können, der nodetool ausführt.

Führen Sie nodetool mit der Option --ssl aus.
```
/opt/apigee/apigee-cassandra/bin/nodetool --ssl -u <jmx-user-name> -pw <jmx-user-password> -h localhost ring
```
Konfigurationsoption 2

Führen Sie nodetool als einzelnen Befehl mit den unten aufgeführten zusätzlichen Parametern aus.
```
/opt/apigee/apigee-cassandra/bin/nodetool -Djavax.net.ssl.trustStore=<path-to-truststore.node1> -Djavax.net.ssl.trustStorePassword=<truststore-password> -Dcom.sun.management.jmxremote.registry.ssl=true -Dssl.enable=true -u <jmx-user-name> -pw <jmx-user-password> -h localhost ring
```

SSL-Konfigurationen rückgängig machen

Wenn Sie die oben beschriebenen SSL-Konfigurationen rückgängig machen möchten, gehen Sie so vor:

apigee-cassandra durch Eingabe von
```
apigee-service apigee-cassandra stop
```
beenden
Entfernen Sie die Zeile conf_cassandra-env_com.sun.management.jmxremote.ssl=true aus der Datei /opt/apigee/customer/application/cassandra.properties.

Kommentieren Sie die folgenden Zeilen in /opt/apigee/apigee-cassandra/source/conf/cassandra-env.sh

# JVM_OPTS="$JVM_OPTS -Djavax.net.ssl.keyStore=/opt/apigee/data/apigee-cassandra/keystore.node0"
# JVM_OPTS="$JVM_OPTS -Djavax.net.ssl.keyStorePassword=keypass"
# JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.registry.ssl=true”

aus

Starte apigee-cassandra, indem du

apigee-service apigee-cassandra start

Entfernen Sie die Umgebungsvariable CASS_JMX_SSL, falls sie festgelegt wurde.
```
unset CASS_JMX_SSL
```
Prüfen Sie, ob apigee-service-basierte Befehle wie ring, stop, backup usw. funktionieren.
--ssl-Schalter nicht mehr mit nodetool verwenden

JMX-Authentifizierung für Cassandra deaktivieren

So deaktivieren Sie die JMX-Authentifizierung für Cassandra:

/opt/apigee/customer/application/cassandra.properties bearbeiten

Entfernen Sie die folgende Zeile aus der Datei:

conf_cassandra-env_com.sun.management.jmxremote.authenticate=true

Führen Sie „configure“ auf Cassandra aus:

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra configure

Starten Sie Cassandra neu:

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra restart

Wiederholen Sie diesen Vorgang auf allen anderen Cassandra-Knoten.

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.

Cassandra JMX-Statistiken

JMX MBeans	JMX-Attribute
ColumnFamilies/apprepo/environments ColumnFamilies/apprepo/organizations ColumnFamilies/apprepo/apiproxy_revisions ColumnFamilies/apprepo/apiproxies ColumnFamilies/audit/audits ColumnFamilies/audit/audits_ref	PendingTasks
	MemtableColumnsCount
	MemtableDataSize
	ReadCount
	RecentReadLatencyMicros
	TotalReadLatencyMicros
	WriteCount
	RecentWriteLatencyMicros
	TotalWriteLatencyMicros
	TotalDiskSpaceUsed
	LiveDiskSpaceUsed
	LiveSSTableCount
	BloomFilterFalsePositives
	RecentBloomFilterFalseRatio
	BloomFilterFalseRatio

Clusterknoten mit nodetool verwalten

Das Nodetool-Dienstprogramm ist eine Befehlszeilenschnittstelle 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:

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 [-u username -pw password] -h localhost ring

Sie müssen Ihren Nutzernamen und Ihr Passwort nur übergeben, wenn Sie die JMX-Authentifizierung für Cassandra aktiviert haben.

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

Allgemeine Informationen zu Knoten (Anruf pro Knoten)

nodetool [-u username -pw password]  -h localhost info

Die Ausgabe des obigen Befehls sieht 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

Status des Thrift-Servers (für die Client-API)
```
nodetool [-u username -pw password] -h localhost statusthrift
```
Die Ausgabe des Befehls sieht in etwa so aus:
```
running
```

Status der Datenstreaming-Vorgänge: Beobachten Sie den Traffic für Cassandra-Knoten:

nodetool [-u username -pw password] -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 Dienstprogramm „nodetool“.

Cassandra-Ressource

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

Apache ZooKeeper

ZooKeeper-Status prüfen

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.
Testen Sie ZooKeeper-Ports, um sicherzustellen, dass Sie auf jedem ZooKeeper-Server eine TCP-Verbindung zu den Ports 2181 und 3888 herstellen können.
Achten Sie darauf, dass 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.

Prüfen Sie den Status:

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

Vierstellige ZooKeeper-Wörter verwenden

ZooKeeper kann mit einer Reihe von Befehlen (Wörter aus vier Buchstaben) überwacht werden, die mithilfe von Netcat (nc) oder Telnet an 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:

Führen Sie den vierstelligen Befehl „ruok“ aus, um zu prüfen, ob der Server ohne Fehler ausgeführt wird. Eine erfolgreiche Antwort gibt „imok“ zurück.
```
echo ruok | nc host 2181
```
Liefert:
```
imok
```

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

Wenn Netcat (nc) nicht verfügbar ist, können Sie alternativ Python 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 jetzt 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.

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

Prüfen Sie mit dem folgenden Befehl, ob der Verwaltungsserver noch mit 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. Die Überwachung und anschließende Optimierung der Cachegröße auf dem OpenLDAP-Server kann sich stark auf die Leistung des Verzeichnisservers auswirken. In den Protokolldateien (opt/apigee/var/log) finden Sie Informationen zum Cache.

Monitoring

Übersicht

JMX- und Management API-Monitoring-Ports

JMX für Monitoring verwenden

JMX aktivieren

JMX-Authentifizierung aktivieren

Mit JConsole überwachen

Mit der Verwaltungs-API überwachen

Dienstprüfungen durchführen

Nutzer-, Organisations- und Bereitstellungsstatus im Blick behalten

Status mit dem Befehl apigee-service prüfen

Postgres-Monitoring

Organisationen und Umgebungen in Postgres prüfen

Analysestatus überprüfen

PostgreSQL-Datenbank

check_postgres.pl-Script verwenden

Datenbankprüfungen ausführen

Systemstatus des Postgres-Prozesses prüfen

Postgres-Ressourcen

Apache Cassandra

JMX-Authentifizierung für Cassandra aktivieren

JMX-Passwortverschlüsselung aktivieren

JMX mit SSL für Cassandra aktivieren

Option 1 (SSL-Argumente in Datei gespeichert)

Option 2 (In Umgebungsvariablen gespeicherte SSL-Argumente)

Option 3 (SSL-Argumente werden direkt an apigee-service übergeben)

Konfigurationsoption 1

Konfigurationsoption 2

SSL-Konfigurationen rückgängig machen

JMX-Authentifizierung für Cassandra deaktivieren

JConsole verwenden: Aufgabenstatistiken überwachen

Cassandra JMX-Statistiken

Clusterknoten mit nodetool verwalten

Cassandra-Ressource

Apache ZooKeeper

ZooKeeper-Status prüfen

Vierstellige ZooKeeper-Wörter verwenden

Test auf LDAP-Ebene

Status mit dem Befehl `apigee-service` prüfen

`check_postgres.pl`-Script verwenden

Option 3 (SSL-Argumente werden direkt an `apigee-service` übergeben)