Was überwacht werden soll

Edge for Private Cloud Version 4.17.09

In einer Produktionsumgebung müssen in der Regel Monitoringmechanismen in einer Apigee Edge for Private Cloud-Bereitstellung aktiviert werden. Diese Monitoringtechniken warnen Netzwerkadministratoren (oder -betreiber) vor einem Fehler oder Ausfall. Jeder generierte Fehler wird in Apigee Edge als Benachrichtigung gemeldet. Weitere Informationen zu Benachrichtigungen finden Sie unter Best Practices für das Monitoring.

Der Einfachheit halber werden Apigee-Komponenten hauptsächlich in zwei Kategorien unterteilt:

  • Apigee-spezifische Java-Serverdienste: Dazu gehören der Verwaltungsserver, der Nachrichtenprozessor, der Qpid-Server und der Postgres-Server.
  • Drittanbieterdienste: Dazu gehören Nginx-Router, Apache Cassandra, Apache ZooKeeper, OpenLDAP, PostgreSQL-Datenbank und Qpid.

Bei einer On-Premise-Bereitstellung von Apigee Edge finden Sie in der folgenden Tabelle einen Überblick über die Parameter, die Sie überwachen können:

Komponente

Systemprüfungen

Statistiken auf Prozessebene

Überprüfungen auf API-Ebene

Nachrichtenflussprüfungen

Komponentenspezifisch

Apigee-spezifische Java-Dienste

Verwaltungsserver

?

?

?

Message Processor

?

?

?

?

Qpid-Server

?

?

?

Postgres-Server

?

?

?

Drittanbieterdienste

Apache Cassandra

?

?

Apache ZooKeeper

?

?

OpenLDAP

?

?

PostgreSQL-Datenbank

?

?

Qpid

?

?

Nginx-Router

?

?

?

Nach der Installation von Apigee Edge können Sie die folgenden Überwachungsaufgaben ausführen, um die Leistung einer Apigee Edge for Private Cloud-Installation zu überwachen.

Systemdiagnosen

Es ist sehr wichtig, die Systemstatusparameter wie CPU-Auslastung, Arbeitsspeicherauslastung und Portverbindung auf einer höheren Ebene zu messen. Sie können die folgenden Parameter überwachen, um sich mit den Grundlagen des Systemzustands vertraut zu machen.

  • CPU-Auslastung: Gibt die grundlegenden Statistiken (Nutzer/System/IO-Wartezeit/Inaktiv) zur CPU-Auslastung an. Beispiel: CPU-Gesamtauslastung, die vom System verwendet wird.
  • Kostenloser/verwendeter Arbeitsspeicher: Gibt die Systemspeicherauslastung in Byte an. Zum Beispiel der vom System verwendete physische Arbeitsspeicher.
  • Speicherplatznutzung: Gibt die Dateisysteminformationen basierend auf der aktuellen Laufwerknutzung an. Beispielsweise der vom System verwendete Festplattenspeicherplatz.
  • Auslastung: Gibt die Anzahl der Prozesse an, die auf die Ausführung warten.
  • Netzwerkstatistik – Netzwerkpakete und/oder übertragene und empfangene Netzwerkpakete sowie Übertragungsfehler zu einer bestimmten Komponente.

Prozesse/Anwendungsprüfungen

Auf Prozessebene können Sie wichtige Informationen zu allen laufenden Prozessen abrufen. Dazu gehören beispielsweise Statistiken zur Speicher- und CPU-Auslastung, die von einem Prozess oder einer Anwendung genutzt werden. Für Prozesse wie qpidd, postgres postmaster, java usw. können Sie Folgendes überwachen:

  • Prozessidentifikation: Identifizieren Sie einen bestimmten Apigee-Prozess. Sie können beispielsweise prüfen, ob ein Java-Prozess des Apigee-Servers vorhanden ist.
  • Thread-Statistiken: Sehen Sie sich die zugrunde liegenden Threading-Muster an, die von einem Prozess verwendet werden. Sie können beispielsweise die maximale Anzahl von Threads und die Anzahl der Threads für alle Prozesse überwachen.
  • Speicherauslastung: Hier sehen Sie die Speichernutzung aller Apigee-Prozesse. Sie können beispielsweise die Parameter wie die Heap-Speichernutzung und die Nicht-Heap-Speichernutzung überwachen, die von einem Prozess verwendet werden.

Prüfungen auf API-Ebene

Auf API-Ebene können Sie prüfen, ob der Server für häufig verwendete API-Aufrufe, die über Apigee geproxyt werden, in Betrieb ist. Sie können beispielsweise eine API-Prüfung für den Verwaltungsserver, den Router und den Nachrichtenprozessor ausführen, indem Sie den folgenden cURL-Befehl aufrufen:

curl http://<host>:<port>/v1/servers/self/up

Dabei ist <host> die IP-Adresse der Apigee Edge-Komponente. Die <port>-Nummer ist für jede Edge-Komponente spezifisch. Beispiel:

Verwaltungsserver: 8080

  • Router: 8081
  • Message Processor: 8082
  • usw.

In den folgenden Abschnitten finden Sie Informationen dazu, wie Sie diesen Befehl für die einzelnen Komponenten ausführen.

Dieser Aufruf gibt „true“ und „false“ zurück. Die besten Ergebnisse erzielen Sie, wenn Sie API-Aufrufe direkt im Back-End ausführen, mit dem die Apigee-Software interagiert. So lässt sich schnell feststellen, ob in der Apigee-Softwareumgebung oder im Back-End ein Fehler vorliegt.

Hinweis: Sie können Ihre API-Proxys auch mit der API-Überwachung von Apigee überwachen. API Health sendet geplante Aufrufe an Ihre API-Proxys und benachrichtigt Sie, wenn sie fehlschlagen und wie. Bei erfolgreichen Aufrufen werden in API Health die Antwortzeiten angezeigt. Sie können sogar benachrichtigt werden, wenn die Antwortlatenz hoch ist. API Health kann Aufrufe von verschiedenen Orten auf der ganzen Welt ausführen, um das API-Verhalten zwischen Regionen zu vergleichen.

Prüfungen des Nachrichtenflusses

Sie können Daten von Routern und Message Processors zu Nachrichtenflussmustern/-statistiken erfassen. So können Sie Folgendes überwachen:

  • Anzahl der aktiven Kunden
  • Anzahl der Antworten (10-, 20-, 30-, 40- und 50-fache)
  • Verbindungsfehler

So können Sie Dashboards für den API-Nachrichtenfluss bereitstellen. Weitere Informationen finden Sie unter:

Router-Systemdiagnose des Message Processor

Der Router implementiert einen Systemdiagnosemechanismus, um festzustellen, welcher der Message Processor wie erwartet funktioniert. Wenn ein Message Processor als ausgefallen oder langsam erkannt wird, kann der Router den Message Processor automatisch aus der Rotation nehmen. In diesem Fall schreibt der Router eine „Mark Down“-Nachricht in die Router-Logdatei unter /opt/apigee/var/log/edge-router/logs/system.log.

Sie können die Router-Logdatei auf diese Nachrichten prüfen. Wenn der Router beispielsweise einen Message Processor aus der Rotation nimmt, schreibt er eine Nachricht in das Protokoll im folgenden Format:

2014-05-06 15:51:52,159 org: env: RPCClientClientProtocolChildGroup-RPC-0 INFO CLUSTER - ServerState.setState() : State of 2a8a0e0c-3619-416f-b037-8a42e7ad4577 is now DISCONNECTED. handle = <MP_IP> at 1399409512159

2014-04-17 12:54:48,512 org: env: nioEventLoopGroup-2-2 INFO HEARTBEAT - HBTracker.gotResponse() : No HeartBeat detected from /<MP_IP>:<PORT> Mark Down

Dabei ist /<MP_IP>:<PORT> die IP-Adresse und die Portnummer des Nachrichten-Prozessors.

Wenn der Router später eine Systemdiagnose durchführt und feststellt, dass der Nachrichtenprozessor ordnungsgemäß funktioniert, setzt er ihn automatisch wieder in die Rotation. Der Router schreibt außerdem eine „Mark Up“-Nachricht in das Protokoll im folgenden Format:

2014-05-06 16:07:29,054 org: env: RPCClientClientProtocolChildGroup-RPC-0 INFO CLUSTER - ServerState.setState() : State of 2a8a0e0c-3619-416f-b037-8a42e7ad4577 is now CONNECTED. handle = <IP> at 1399410449054

2014-04-17 12:55:06,064 org: env: nioEventLoopGroup-4-1 INFO HEARTBEAT - HBTracker.updateHB() : HeartBeat detected from /<IP>:<PORT> Mark Up