Was überwacht werden soll

Edge for Private Cloud Version 4.18.01

Im Allgemeinen müssen in einer Produktionseinrichtung Monitoringmechanismen in einem Apigee Edge für die Bereitstellung einer privaten Cloud aktiviert werden. Mit diesen Monitoringtechniken werden Netzwerkadministratoren (oder Betreiber) vor einem Fehler oder Fehler gewarnt. Jeder generierte Fehler wird als Benachrichtigung in Apigee Edge gemeldet. Weitere Informationen zu Benachrichtigungen finden Sie unter Best Practices für Monitoring.

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

  • Apigee-spezifische Java Server-Dienste: Dazu gehören Management Server, Message Processor, Qpid Server und Postgres Server.
  • Drittanbieterdienste: Dazu gehören Nginx Router, Apache Cassandra, Apache ZooKeeper, OpenLDAP, PostgreSQL-Datenbank und Qpid.

In einer lokalen Bereitstellung von Apigee Edge bietet die folgende Tabelle einen schnellen Überblick über die Parameter, die Sie überwachen können:

Komponente

Systemprüfungen

Statistiken auf Prozessebene

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

?

?

?

Im Allgemeinen können Sie nach der Installation von Apigee Edge die folgenden Monitoringaufgaben ausführen, um die Leistung einer Installation von Apigee Edge für die Private Cloud zu verfolgen.

Systemstatusprüfungen

Es ist sehr wichtig, die Parameter des Systemzustands wie CPU-Auslastung, Arbeitsspeicherauslastung und Portverbindung auf einer höheren Ebene zu messen. Sie können die folgenden Parameter überwachen, um grundlegende Informationen zum Systemzustand zu erhalten.

  • CPU Utilization (CPU-Auslastung): Gibt die grundlegenden Statistiken (Nutzer-/System-/E/A-Wartezeit/-inaktivität) zur CPU-Auslastung an. Zum Beispiel die vom System insgesamt genutzte CPU.
  • Free/Used Memory (Kostenloser/Verwendeter Arbeitsspeicher): Gibt die Auslastung des Systemarbeitsspeichers in Byte an. Zum Beispiel der vom System verwendete physische Speicher.
  • Speicherplatznutzung: Gibt die Dateisysteminformationen basierend auf der aktuellen Laufwerksnutzung an. Zum Beispiel der vom System belegte Festplattenspeicher.
  • Load Average (Durchschnittliche Last): Gibt die Anzahl der Prozesse an, die noch auszuführen sind.
  • Netzwerkstatistik: Übertragen und empfangene Netzwerkpakete und/oder -byte sowie die Übertragungsfehler zu einer bestimmten Komponente.

Prozesse/Anwendungsprüfungen

Auf Prozessebene können Sie wichtige Informationen zu allen ausgeführten Prozessen ansehen. Dazu gehören beispielsweise Speicher- und CPU-Nutzungsstatistiken, die von einem Prozess oder einer Anwendung verwendet werden. Für Prozesse wie qpidd, postgres postmaster, Java usw. können Sie Folgendes überwachen:

  • Prozesserkennung: Identifizieren Sie einen bestimmten Apigee-Prozess. Sie können beispielsweise überwachen, ob ein Apigee-Server-Java-Prozess vorhanden ist.
  • Thread-Statistiken: Sehen Sie sich die zugrunde liegenden Threading-Muster an, die ein Prozess verwendet. Sie können beispielsweise die maximale Anzahl von Threads und die Anzahl der Threads für alle Prozesse überwachen.
  • Arbeitsspeicherauslastung: Sehen Sie sich die Arbeitsspeichernutzung für alle Apigee-Prozesse an. Sie können beispielsweise Parameter wie die Heap-Arbeitsspeichernutzung und die von einem Prozess verwendete Nicht-Heap-Arbeitsspeichernutzung überwachen.

Prüfungen auf API-Ebene

Auf API-Ebene können Sie überwachen, ob der Server für häufig verwendete API-Aufrufe, die von Apigee weitergeleitet werden, aktiv ist. Sie können beispielsweise eine API-Prüfung für den Verwaltungsserver, den Router und den Message Processor durchfü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 gilt für jede Edge-Komponente. Beispiel:

Verwaltungsserver: 8080

  • Router: 8081
  • Message Processor: 8082
  • und so weiter

Informationen zum Ausführen dieses Befehls für jede Komponente finden Sie in den einzelnen Abschnitten unten.

Dieser Aufruf gibt „true“ und „false“ zurück. Die besten Ergebnisse erzielen Sie, wenn Sie API-Aufrufe auch direkt im Back-End ausführen (mit dem die Apigee-Software interagiert), um schnell festzustellen, ob ein Fehler in der Apigee-Softwareumgebung oder im Back-End vorliegt.

Hinweis: Zum Überwachen Ihrer API-Proxys können Sie auch den API-Status von Apigee verwenden. API Health führt geplante Aufrufe an Ihre API-Proxys durch und benachrichtigt Sie, wenn und wie sie fehlschlagen. Wenn Aufrufe erfolgreich sind, zeigt Ihnen der API-Integritätszustand die Antwortzeiten an und kann Sie sogar benachrichtigen, wenn die Antwortlatenz hoch ist. API Health kann von verschiedenen Standorten weltweit Aufrufe senden, um das API-Verhalten zwischen Regionen zu vergleichen.

Prüfung des Nachrichtenflusses

Sie können Daten von Routern und Message Processorn über das Muster bzw. die Statistiken des Nachrichtenflusses erfassen. So können Sie Folgendes überwachen:

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

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

Router-Systemdiagnose des Message Processor

Der Router implementiert einen Systemdiagnosemechanismus, der feststellt, welche der Message Processorn erwartungsgemäß funktionieren. Wenn ein Message Processor als inaktiv oder langsam erkannt wird, kann der Router den Message Processor automatisch aus der Rotation entfernen. In diesem Fall schreibt der Router eine „Markdown“-Meldung in die Router-Logdatei unter /opt/apigee/var/log/edge-router/logs/system.log.

Sie können die Router-Logdatei auf diese Meldungen überwachen. Wenn der Router beispielsweise einen Message Processor aus der Rotation hebt, schreibt er eine Nachricht in folgendem Format in das Log:

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

wobei /<MP_IP>:<PORT> die IP-Adresse und Portnummer des Message Processor ist.

Wenn der Router später eine Systemdiagnose durchführt und feststellt, dass der Message Processor ordnungsgemäß funktioniert, setzt der Router den Message Processor automatisch zurück in die Rotation. Der Router schreibt außerdem eine „Mark Up“-Meldung in folgendem Format in das Protokoll:

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