Was wird überwacht?

Im Allgemeinen sollten Sie in einer Produktionsumgebung Monitoring-Mechanismen in einer Apigee Edge for Private Cloud-Bereitstellung aktivieren. Diese Überwachungstechniken warnen Netzwerkadministratoren (oder ‑betreiber) vor einem Fehler oder Ausfall. Jeder generierte Fehler wird als Benachrichtigung in Apigee Edge gemeldet. Weitere Informationen zu Benachrichtigungen finden Sie unter Best Practices für das Monitoring.

Apigee-Komponenten werden hauptsächlich in zwei Kategorien eingeteilt:

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

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

Nach der Installation von Apigee Edge können Sie im Allgemeinen die folgenden Monitoring-Aufgaben ausführen, um die Leistung einer Apigee Edge for Private Cloud-Installation zu verfolgen.

Systemdiagnosen

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

• CPU-Auslastung:Gibt die grundlegenden Statistiken (Nutzer/System/E/A-Wartezeit/Leerlauf) zur CPU-Auslastung an. Beispiel: Die vom System verwendete CPU-Gesamtzeit.
• Kostenloser/verwendeter Arbeitsspeicher:Gibt die Arbeitsspeichernutzung des Systems in Byte an. Beispiel: vom System verwendeter physischer Arbeitsspeicher.
• Speicherplatznutzung:Gibt die Dateisysteminformationen basierend auf der aktuellen Festplattennutzung an. Beispiel: vom System verwendeter Festplattenspeicher.
• Load Average (Durchschnittliche Systemlast): Gibt die Anzahl der Prozesse an, die auf die Ausführung warten.
• Netzwerkstatistiken:Übertragene und empfangene Netzwerkpakete und/oder ‑Byte sowie Übertragungsfehler einer bestimmten Komponente.

Prozesse/Anwendungsprüfungen

Auf Prozessebene können Sie wichtige Informationen zu allen laufenden Prozessen aufrufen. Dazu gehören beispielsweise Statistiken zur Speicher- und CPU-Nutzung eines Prozesses oder einer Anwendung. Für Prozesse wie Qpid, Postgres Postmaster und Java können Sie Folgendes überwachen:

• Prozessidentifizierung: Identifizieren Sie einen bestimmten Apigee-Prozess. Sie können beispielsweise überwachen, ob ein Apigee-Server-Java-Prozess vorhanden ist.
• Thread-Statistiken: Hier sehen Sie die zugrunde liegenden Threading-Muster, die von einem Prozess verwendet werden. Sie können beispielsweise die maximale Anzahl von Threads und die Anzahl von Threads für alle Prozesse überwachen.
• Speicherauslastung: Hier sehen Sie die Speichernutzung für alle Apigee-Prozesse. Sie können beispielsweise die von einem Prozess verwendete Heap- und Non-Heap-Speichernutzung überwachen.

Prüfungen auf API-Ebene

Auf API-Ebene können Sie prüfen, ob ein Server für häufig verwendete API-Aufrufe, die von Apigee weitergeleitet werden, betriebsbereit ist. Sie können beispielsweise einen API-Check auf dem Management Server, Router und 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 ist für jede Edge-Komponente spezifisch. Beispiel:

Verwaltungsserver: 8080

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

Informationen zum Ausführen dieses Befehls für die einzelnen Komponenten finden Sie in den folgenden Abschnitten.

Dieser Aufruf gibt „true“ und „false“ zurück. Um optimale Ergebnisse zu erzielen, können Sie API-Aufrufe auch direkt im Backend ausführen (mit dem die Apigee-Software interagiert), um schnell festzustellen, ob ein Fehler in der Apigee-Softwareumgebung oder im Backend vorliegt.

Prüfungen des Nachrichtenflusses

Sie können Daten von Routern und Message Processors zu Nachrichtenflussmustern und ‑statistiken erfassen. So können Sie Folgendes im Blick behalten:

• Anzahl der aktiven Clients
• Anzahl der Antworten (10‑mal, 20‑mal, 30‑mal, 40‑mal und 50‑mal)
• Verbindungsfehler

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

Router-Systemdiagnose des Message Processor

Der Router implementiert einen Systemdiagnosemechanismus, um zu ermitteln, welche Message Processors wie erwartet funktionieren. Wenn ein Nachrichtenprozessor als ausgefallen oder langsam erkannt wird, kann der Router ihn automatisch aus dem Umlauf nehmen. In diesem Fall schreibt der Router „Mark Down“-Meldungen in die Router-Logdatei unter /opt/apigee/var/log/edge-router/logs/system.log.

Sie können die Router-Logdatei auf diese Meldungen hin überwachen. Wenn der Router beispielsweise einen Message Processor aus dem Umlauf nimmt, schreibt er eine Meldung in das Log, die so aussieht:

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 Portnummer des Message Processor.

Wenn der Router später eine Systemdiagnose durchführt und feststellt, dass der Message Processor ordnungsgemäß funktioniert, nimmt der Router den Message Processor automatisch wieder in die Rotation auf. Der Router schreibt außerdem eine „Mark Up“-Nachricht in das Log 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