Was überwacht werden soll

Edge for Private Cloud v4.18.01

In einer Produktionsumgebung müssen in der Regel Monitoringmechanismen in einer Apigee Edge for Private Cloud-Bereitstellung aktiviert werden. Diese Monitoring-Techniken warnen die 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.

Zur Vereinfachung 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 einen Überblick über den Systemstatus zu erhalten.

  • 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. Beispielsweise 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.
  • Netzwerkstatistiken: Gesendet und empfangene Netzwerkpakete und/oder ‑Byte sowie die Übertragungsfehler 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.
  • Threadstatistiken: Hier sehen Sie die zugrunde liegenden Threadmuster, die ein Prozess verwendet. 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
  • Nachrichtenprozessor: 8082
  • usw.

In den folgenden Abschnitten finden Sie Informationen dazu, wie Sie diesen Befehl für jede Komponente ausführen.

Dieser Aufruf gibt „true“ und „false“ zurück. Für optimale Ergebnisse können Sie auch API-Aufrufe direkt im Backend ausführen, mit dem die Apigee-Software interagiert, um schnell zu ermitteln, ob ein Fehler in der Apigee-Softwareumgebung oder im Backend 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 im Blick behalten:

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

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

Router-Systemdiagnose des Message Processors

Der Router implementiert einen Mechanismus zur Systemdiagnose, um zu ermitteln, welche der Nachrichtenprozessoren wie erwartet funktionieren. Wenn ein Nachrichtenprozessor als ausgefallen oder langsam erkannt wird, kann der Router ihn automatisch aus der Rotation entfernen. 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