Monitoring

Edge for Private Cloud v4.18.05

In diesem Dokument werden die Monitoring-Techniken von Komponenten beschrieben, die von einer lokalen Bereitstellung von Apigee Edge.

Übersicht

Edge unterstützt mehrere Möglichkeiten, um Details zu Diensten abzurufen und ihre Status. In der folgenden Tabelle sind die Überprüfungstypen aufgeführt, die Sie für die einzelnen Dienst:

Dienst JMX:*
Arbeitsspeichernutzung
Mgmt API:
Service Check
Management API:
Nutzer-/Organisations-/Bereitstellungsstatus
Management-API:
axstatus
Datenbankprüfung apigee-service-Status
Verwaltungsserver
Message Processor
Postgres
Qpid
Router
Weitere Informationen Weitere Informationen Weitere Informationen Weitere Informationen Weitere Informationen Weitere Informationen
* Bevor Sie JMX verwenden können, müssen Sie es aktivieren. wie unter JMX aktivieren beschrieben.

Monitoring-Ports für JMX und Management API

Jede Komponente unterstützt JMX- und Management API-Überwachungsaufrufe an verschiedenen Ports. Die 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 verwenden

Die Monitoring-Prozesse für den Management Server, Message Processor, Qpid und Postgres JMX verwenden. JMX ist jedoch standardmäßig nur für Cassandra aktiviert und standardmäßig für alle anderen Edge-Komponenten. Daher müssen Sie JMX für jede Komponente einzeln aktivieren, bevor Sie überwachen können.

Die JMX-Authentifizierung ist nicht standardmäßig aktiviert. Sie können die JMX-Authentifizierung für alle aktivieren mit Ausnahme von Cassandra.

JMX aktivieren

JMX ist standardmäßig nur für Cassandra aktiviert und für alle anderen Edge-Geräte standardmäßig deaktiviert. Komponenten. 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 Produktion befinden sich diese Konfigurationsdateien auf verschiedenen Computern.

    Wählen Sie auf jedem Server einen der folgenden Speicherorte für Dateien 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

    Die Konfigurationsdatei des Verwaltungsservers befindet sich beispielsweise auf /opt/apigee/edge-management-server/bin/start

  2. Fügen Sie dem exec die folgenden com.sun.management.jmxremote-Optionen hinzu mit der Komponente beginnt:
    -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. So rufen Sie das JMX Ihres Dienstes ab: Weitere Informationen finden Sie unter Monitoring-Ports für JMX und Management API.

    Um beispielsweise JMX auf dem Verwaltungsserver zu aktivieren, fügen Sie Folgendes zur Konfigurationsdatei des Servers:

    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, Dienst eine eigene Portnummer hat.

    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 aktivieren außer Cassandra-Komponenten 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 aktivieren mit Ausnahme von Cassandra.

Führen Sie zum Aktivieren der JMX-Authentifizierung die folgende change_jmx_auth-Aktion für alle Knoten:

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

Wobei:

  • component ist einer der folgenden Werte: <ph type="x-smartling-placeholder">
      </ph>
    • edge-management-server
    • edge-message-processor
    • edge-postgres-server
    • edge-qpid-server
    • edge-router
  • options gibt Folgendes an: <ph type="x-smartling-placeholder">
      </ph>
    • -u username
    • -p password
    • -e [y|n] (aktivieren oder deaktivieren)
  • config_file gibt den Speicherort einer Konfigurationsdatei an, in der Sie definieren Folgendes: <ph type="x-smartling-placeholder">
      </ph>
    • JMX_USERNAME=username
    • JMX_ENABLED=y|n
    • JMX_PASSWORD=password (wenn nicht festgelegt oder nicht mit übergeben -p, Sie werden aufgefordert)

Sie können entweder die Befehlszeilenoptionen oder die Konfigurationsdatei verwenden, um den Nutzernamen zu definieren, Passwort und den Status „Aktivieren“/„Deaktivieren“. Sie geben nicht sowohl einen Satz von Optionen als auch eine Konfiguration an -Datei.

Im folgenden Beispiel wird die JMX-Authentifizierung für den Verwaltungsserver mit dem folgenden Befehl aktiviert: Linienoptionen:

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

Im folgenden Beispiel wird eine Konfigurationsdatei anstelle von Befehlszeilenoptionen 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 Nutzername und Passwort.

Um die JMX-Authentifizierung in der Befehlszeile zu deaktivieren, verwenden Sie den String "-e n" wie in folgendem Beispiel gezeigt: Das Beispiel zeigt:

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

Mit JConsole überwachen

Verwenden Sie die JConsole (ein JMX-konformes Tool), um Systemdiagnosen und Verarbeitungsstatistiken zu verwalten und zu überwachen. Mit der JConsole können Sie von Ihren Servern bereitgestellte JMX-Statistiken in einem grafische Benutzeroberfläche. Weitere Informationen finden Sie unter JConsole verwenden

Die JConsole verwendet die folgende Dienst-URL zum Überwachen der JMX-Attribute (MBeans), die über JMX:

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 ausführen möchten. überwachen.

Um den Verwaltungsserver beispielsweise zu überwachen, geben Sie einen Befehl wie den folgenden aus (vorausgesetzt, lautet die IP-Adresse des Servers 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. Für andere finden Sie unter Monitoring-Ports für JMX und Management API.

Die folgende Tabelle zeigt die generischen JMX-Statistiken:

JMX MBeans JMX-Attribute

Speicher

HeapMemoryUsage

NonHeapMemoryUsage

Nutzung

Mit der Management API im Blick behalten

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

Dienstprüfungen ausführen

Die Management API bietet mehrere Endpunkte zur Überwachung und Diagnose von Problemen mit Ihrem . Zu diesen Endpunkten gehören:

Endpunkt Beschreibung
/servers/self/up

Prüft, ob ein Dienst ausgeführt wird. Für diesen API-Aufruf ist es nicht erforderlich, authentifizieren.

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 eine Antwort ähnlich der folgenden (je nachdem, um welchen Dienst es sich handelt und wie Sie ihn überprüft haben):

curl: Failed connect to localhost:port_number; Connection refused
/servers/self

Gibt unter anderem folgende Informationen zum Dienst zurück:

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

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

Um diese Endpunkte zu verwenden, rufen Sie ein Dienstprogramm wie curl mit Befehlen auf, die den Parameter folgende Syntax:

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 in Server haben, können Sie „localhost“ verwenden. Andernfalls geben Sie auch die IP-Adresse des Servers an. als Nutzername und Passwort ein.
  • port_number ist der Port der Verwaltungs-API für den Server, den Sie prüfen möchten. Dies ist für jeden Komponententyp einen eigenen Port. Zum Beispiel Der Port der Verwaltungs-API ist 8080. Eine Liste der zu verwendenden Management API-Portnummern finden Sie unter Monitoring-Ports für JMX und Management API

Wenn du das Format der Antwort ändern möchtest, kannst du den Accept-Header so angeben: &quot;application/json&quot; oder „application/xml“.

Im folgenden Beispiel wird der Status des Routers auf localhost (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):

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

Nutzer, Organisation und Bereitstellungsstatus überwachen

Mit der Management API können Sie den Nutzer-, Organisations- und Bereitstellungsstatus Ihrer Proxys auf Verwaltungsservern und Message Processors durch Ausführung der folgenden Befehle:

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 die Nachricht Prozessor.

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

Der Server sollte eine Meldung vom Typ „Bereitgestellt“ zurückgeben, Status für alle Anrufe angezeigt. Wenn das nicht funktioniert, gehen Sie so vor:

  1. Prüfen Sie die Serverprotokolle auf Fehler. Die Protokolle befinden sich unter: <ph type="x-smartling-placeholder">
      </ph>
    • Verwaltungsserver: opt/apigee/var/log/edge-management-server
    • Nachrichtenverarbeiter: opt/apigee/var/log/edge-message-processor
  2. Rufe den Server auf, um zu prüfen, ob er ordnungsgemäß 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 Fehler in Ihren Edge-Diensten mit dem Befehl apigee-service beheben, wenn Sie auf dem Server angemeldet sind, auf dem der Dienst ausgeführt wird.

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
    • Nachrichtenverarbeiter: 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 apigee-service status-Befehl, den Sie zuvor oder mithilfe der Management API verwendet haben im Abschnitt Mit der Verwaltungs-API überwachen beschrieben.

    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 beim Server angemeldet sind und „localhost“ verwenden können. als Hostname. Geben Sie die IP-Adresse an, um den Status per Fernzugriff mit der Management API zu prüfen Adresse des Servers und fügen Sie den Nutzernamen und das Passwort des Systemadministrators in Ihre API ein anrufen.

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 auf Postgres prüfen

Sie können nach Organisations- und Umgebungsnamen suchen, die auf dem Postgres-Server eingerichtet sind indem Sie den folgenden curl-Befehl ausführen:

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 überprüfen, indem Sie Folgendes ausgeben: Befehl curl:

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

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

{
  "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 des Postgres verwenden können. Datenbank.

Skript check_postgres.pl verwenden

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

Vor der Ausführung des Skripts:

  1. Sie müssen das Skript check_postgres.pl auf jedem Postgres-Knoten installieren.
  2. Sie müssen perl-Time-HiRes.x86_64 installiert haben, ein Perl-Modul, das implementiert hochauflösende Wecker, Ruhemodus-Timer, gettimeofday- und Intervall-Timer. Zum Beispiel haben Sie können Sie es mit dem folgenden Befehl installieren:
    yum install perl-Time-HiRes.x86_64
  3. CentOS 7: Installieren Sie vor der Verwendung von check_postgres.pl unter CentOS v7 die perl-Data-Dumper.x86_64 U/min.

check_postgres.pl-Ausgabe

Die Standardausgabe der API-Aufrufe mit check_postgres.pl ist Nagios kompatibel sind. Führen Sie nach der Installation des Skripts folgende 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. Anzahl der zur Datenbank eingehenden Verbindungen prüfen und mit der maximal zulässigen Anzahl vergleichen Verbindungen:
    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 Organisation und der Umgebung, 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. Bei PostgreSQL anmelden mit dem folgenden Befehl:

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

Führen Sie dann diesen Befehl aus:

\d analytics."org.env.fact"

Status des Postgres-Prozesses prüfen

Sie können API-Prüfungen auf der Postgres-Maschine durchführen, indem Sie den folgenden curl aufrufen. Befehl:

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 die Postgres-Prozess läuft nicht und gibt den Status INACTIVE zurück.

Postgres-Ressourcen

Weitere Informationen zum Monitoring des Postgres-Dienstes finden Sie hier:

Apache Cassandra

JConsole verwenden: Aufgabenstatistiken überwachen

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

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

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

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

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

Nodetool zum Verwalten von Clusterknoten verwenden

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

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

  1. Allgemeine Anrufinformationen (auch für einzelne Cassandra-Knoten möglich): Suchen Sie nach dem „Nach oben“ und „Normal“ für alle Knoten.
    nodetool -h localhost ring

    Die Ausgabe des obigen Befehls sieht 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 (Aufruf pro Knoten)
    nodetool -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
  3. Status des Secondhand-Servers (Bereitstellungsclient-API)
    nodetool -h localhost statusthrift

    Die Ausgabe des obigen Befehls sieht so aus:

    running
  4. Status von Datenstreamingvorgängen: Beobachten Sie den Traffic für Cassandra-Knoten:
    nodetool -h localhost netstats

    Die Ausgabe des obigen Befehls sieht 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 findest du unter Informationen zum Dienstprogramm „nodetool“

Cassandra-Monitoring (Benutzeroberfläche)

Weitere Informationen finden Sie in der DataStax Opscenter-URL http://www.datastax.com/products/opscenter.

Cassandra-Ressource

Sehen Sie sich die folgende URL an: http://www.datastax.com/docs/1.0/operations/monitoring.

Apache ZooKeeper

ZooKeeper-Status prüfen

  1. Vergewissern Sie sich, dass 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 eine TCP-Verbindung zu den Ports 2181 und 2181 herstellen können. 3888 auf jedem ZooKeeper-Server.
  3. Achten Sie darauf, dass Sie Werte aus der ZooKeeper-Datenbank lesen können. Mit ZooKeeper verbinden Clientbibliothek (oder /opt/apigee/apigee-zookeeper/bin/zkCli.sh) und liest einen Wert aus der Datenbank.
  4. Prüfen Sie den Status:
    /opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper status

ZooKeeper-Wörter verwenden

ZooKeeper kann mit einem kurzen Satz von Befehlen (aus vier Buchstaben bestehende Wörter) überwacht werden, die an mit netcat (nc) oder telnet an Port 2181 an.

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

Beispiel:

  • srvr: Listet alle Details für den Server auf.
  • stat: Listet kurze Details zum Server und den verbundenen Clients auf.

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

  1. Führen Sie den aus vier Buchstaben bestehenden Befehl „ruok“ aus, um zu testen, ob der Server fehlerfrei ausgeführt wird. A Die erfolgreiche Antwort gibt "imok" zurück.
    echo ruok | nc host 2181

    Liefert:

    imok
  2. Führen Sie den aus vier Buchstaben bestehenden Befehl stat aus, um eine Liste der Serverleistung und der verbundenen Kundenstatistiken:
    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 alternativ Python verwenden. Datei erstellen namens zookeeper.py, der 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

LDAP-Level-Test

Sie können OpenLDAP überwachen, um zu sehen, ob die spezifischen Anfragen ordnungsgemäß verarbeitet werden. In Suchen Sie nach einer bestimmten Suchanfrage, die das richtige Ergebnis liefert.

  1. Verwenden Sie ldapsearch (yum install openldap-clients), um den Eintrag abzufragen des Systemadministrators. Dieser Eintrag wird zur Authentifizierung aller API-Aufrufe verwendet.
    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 zur Eingabe des LDAP-Administratorpassworts aufgefordert:

    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 Zugriffe auf das Laufwerk zu reduzieren. und damit die Systemleistung verbessern. Monitoring und anschließendes Anpassen der Cache-Größe in der Der OpenLDAP-Server kann die Leistung des Verzeichnisservers erheblich beeinträchtigen. Sie können sich das Protokoll ansehen. -Dateien (opt/apigee/var/log), um Informationen zum Cache abzurufen.