Diese Seite wurde von der Cloud Translation API übersetzt.

Trace-Sitzung kann nicht erstellt werden

Sie sehen die Dokumentation zu Apigee Edge.
Zur Apigee X-Dokumentation weitere Informationen

Symptom

Der Nutzer kann keine Trace-Sitzung in der Edge-Benutzeroberfläche erstellen.

Fehlermeldung

In der Edge-Benutzeroberfläche wird eine Fehlermeldung angezeigt, wie unten dargestellt:

Error creating trace session for API proxy <api proxy name>, revision <revision number>, environment <environment name>.
Failed to create DebugSession <session number>

Hier ist der Screenshot einer Beispielfehlermeldung in der Edge-Benutzeroberfläche:

Mögliche Ursachen

Mögliche Ursachen für diesen Fehler:

Ursache	Beschreibung	Gilt für die Anleitung zur Fehlerbehebung
Problem mit der Netzwerkverbindung	Kommunikationsfehler zwischen Management Server und Message Processor aufgrund von Problemen mit der Netzwerkverbindung oder Firewallregeln.	Edge Private Cloud-Nutzer
Umgebung nicht auf Message Processor geladen	Die spezifische Umgebung, in der Sie versuchen, den Trace zu aktivieren, wurde aufgrund eines Fehlers nicht auf den Message Processor geladen.
Veraltete Einträge für den Nachrichtenprozessor	Der Verwaltungsserver verweist auf nicht vorhandene (veraltete) Message Processor.
Nachrichtenprozessor nicht erreichbar	Message Processor wurde gestoppt oder ist nicht mehr erreichbar.
Problem mit hoher Ressourcenauslastung	Die Ressourcenauslastung (CPU, Arbeitsspeicher oder Last) des Message Processor bzw. die Nachrichtenprozessoren ist hoch.
API-Proxy nicht auf einem oder mehreren Message Processorn bereitgestellt	Der API-Proxy kann aufgrund fehlender Ereignisbenachrichtigungen während der Bereitstellung nicht auf einem oder mehreren Message Processorn bereitgestellt werden.
Problem mit der Edge-Benutzeroberfläche	Edge-UI kann aufgrund eines Fehlers keine Trace-Sitzung erstellen.

Häufige Diagnoseschritte

Führen Sie diese Verwaltungs-API aus:

curl -v <management-server-host>:8080/v1/runtime/organizations/<org-name>/environments/<env-name>/apis/<apiproxy-name>/revisions/<revision-number>/debugsessions -u <user>

Notieren Sie gegebenenfalls Fehlermeldungen. Fahren Sie mit Netzwerkverbindungsproblem fort.
Wenn Sie eine erfolgreiche Antwort erhalten, bedeutet das, dass die Trace-Sitzung über die Management API erstellt werden kann. Es könnte jedoch ein mögliches Problem mit der Edge-Benutzeroberfläche vorliegen, sodass die Trace-Sitzung nicht in der Benutzeroberfläche erstellt werden kann. Fahren Sie mit Problem mit der Edge-Benutzeroberfläche fort.

Ursache: Problem mit der Netzwerkverbindung

Diagnose

Prüfen Sie das Management Server-Protokoll /opt/apigee/var/log/edge-management-server/logs/system.log und sehen Sie nach, ob beim Erstellen der Trace-/Debug-Sitzung Fehler aufgetreten sind.

Beispielfehler im Verwaltungsserverprotokoll

2018-02-08 09:08:21,310 org:myorg env:uat  qtp1073741635-1074 ERROR DISTRIBUTION - DebugSessionAPI.createDebugSession() : createDebugSession : Unable to connect to the server with UUID cedeabd2-e4d1-40bb-8f18-d6afc8835e5b
org.apache.http.conn.HttpHostConnectException: Connect to 10.84.75.92:8082 [/10.84.75.92] failed: Connection refused
    at org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:140) ~[httpclient-4.3.5.jar:4.3.5]
    at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:318) ~[httpclient-4.3.5.jar:4.3.5]
    at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:363) ~[httpclient-4.3.5.jar:4.3.5]
...<snipped>
Caused by: java.net.ConnectException: Connection refused
    at java.net.PlainSocketImpl.socketConnect(Native Method) ~[na:1.8.0_65]
    at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) ~[na:1.8.0_65]
...<snipped>

Der oben stehende Beispielfehler zeigt, dass der Verwaltungsserver versucht, über Port 8082 eine Verbindung zum Message Processor herzustellen, den Fehler "Verbindung abgelehnt". Daher kann der Verwaltungsserver die Trace-Sitzung nicht erstellen.
Wenn keine Fehler im Zusammenhang mit der Netzwerkverbindung oder ein ähnlicher Fehler wie der im Beispiel oben gezeigte angezeigt wird, fahren Sie mit Umgebung nicht auf dem Message Processor geladen fort.
Wenn Sie Fehler im Zusammenhang mit der Netzwerkverbindung oder einen ähnlichen Fehler wie im obigen Beispiel feststellen, führen Sie die folgenden Schritte aus.
Testen Sie die Verbindung vom Management Server zum Message Processor an Port 8082 mit den folgenden Schritten:
1. Wenn Telnet verfügbar ist, verwenden Sie Telnet:
```
telnet <MessageProcessor_IP> 8082
```
2. Wenn Telnet nicht verfügbar ist, prüfen Sie die Konnektivität mit netcat wie folgt:
```
nc -vz <MessageProcessor_IP> 8082
```
3. Wenn Sie die Antwort „Verbindung abgelehnt“ oder „Zeitüberschreitung bei der Verbindung“ erhalten, fahren Sie mit dem nächsten Schritt fort.
Melden Sie sich bei jedem Message Processor mit der entsprechenden IP-Adresse an, bei der der Fehler angezeigt wurde, und führen Sie die folgenden Schritte aus:
1. Prüfen Sie, ob der Message Processor Port 8082 überwacht:
```
netstat -an | grep LISTEN | grep 8082
```
2. Wenn der Message Processor Port 8082 überwacht, fahren Sie mit Schritt 7 fort.
3. Wenn der Message Processor Port 8082 nicht überwacht, starten Sie ihn mit diesem Befehl neu:
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```
4. Warten Sie mit dem folgenden Befehl, bis der Message Processor vollständig gestartet wurde:
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor wait_for_ready
```
5. Sobald der Message Processor hochgefahren ist, prüfen Sie noch einmal, ob er Port 8082 überwacht.
6. Wenn der Message Processor Port 8082 überwacht, fahren Sie mit Schritt 7 fort.
Prüfen Sie, ob Sie die Trace-Sitzung jetzt in der Benutzeroberfläche starten können. Wenn das Problem nicht mehr auftritt, überspringen Sie die folgenden Schritte.
Wenn der Message Processor ausgeführt wird und Port 8082 überwacht, Sie aber dennoch keine Verbindung von den anderen Servern wie dem Management Server herstellen können, muss die externe Verbindung wahrscheinlich von einer Firewall blockiert werden.
Prüfen Sie die Firewallregeln mit dem entsprechenden Befehl. Sie können beispielsweise den Befehl iptables ausführen, um alle auf Ihrem System definierten Firewallregeln aufzulisten:
```
iptables -L -n
```
Wenn für den Port 8082 keine Firewallregeln festgelegt sind, fahren Sie mit Problem mit hoher Ressourcenauslastung fort.
Wenn auf Port 8082 Firewallregeln eingerichtet sind, fahren Sie mit dem Abschnitt „Lösung“ unten fort.

Lösung

Wenden Sie sich an Ihren Netzwerkadministrator, um eingehenden und ausgehenden Traffic über Port 8082 von externen Servern zuzulassen.

Wenn das Problem weiterhin besteht, lesen Sie den Artikel Diagnoseinformationen müssen erfasst werden.

Ursache: Umgebung wurde nicht auf Message Processor geladen

Diagnose

Prüfen Sie die /opt/apigee/var/log/edge-management-server/logs/system.log-Protokolle des Management Servers auf Fehler beim Erstellen der Trace-/Debug-Sitzung.

Beim Erstellen der Trace-/Debug-Sitzung wird möglicherweise eine Fehlermeldung wie „no valid answers from MP(s)“ angezeigt, wie unten gezeigt:

2018-01-30 08:28:09,721 org:mynonprod env:uat  qtp2007599722-712162 ERROR DISTRIBUTION - DebugSessionAPI.createDebugSession() : no valid responses from MP(s), throwing error
2018-01-30 08:28:09,723 org:mynonprod env:uat  qtp2007599722-712162 ERROR REST - CustomJAXRSInvoker.performInvocation() : CustomJAXRSInvoker.performInvocation : Method com.apigee.distribution.DebugSessionAPI.createDebugSession threw an exception.
2018-01-30 08:28:09,724 org:mynonprod env:uat  qtp2007599722-712162 ERROR REST - ExceptionMapper.toResponse() : Error occurred : Failed to create DebugSession 1517297564678
2018-01-30 08:28:09,724 org:mynonprod env:uat  qtp2007599722-712162 ERROR REST - ExceptionMapper.toResponse() : Returning error response : ErrorResponse{errorCode = distribution.CreateDebugSessionFailed, errorMessage = Failed to create DebugSession 1517297564678}

Dieser Fehler weist darauf hin, dass die Message Processor(e) aus irgendeinem Grund nicht an den Management Server antworten.

Wenn kein Fehler wie im obigen Beispiel angezeigt wird, fahren Sie mit Veraltete Einträge für den Nachrichtenprozessor fort.
Wenn ein ähnlicher Fehler wie im obigen Beispiel auftritt, gehen Sie so vor:
Eine der wahrscheinlichsten Ursachen für diesen Fehler besteht darin, dass die Umgebung, in der Sie versuchen, die Ablaufverfolgungssitzung zu erstellen, nicht auf den Message Processor geladen wurde.
Melden Sie sich bei jedem der Message Processor an und prüfen Sie mit dem folgenden Befehl, ob die Umgebung, in der Sie die Trace-Sitzung erstellen möchten, auf den Message Processor geladen wird:
```
curl -s http://localhost:8082/v1/runtime/organizations/<org-name>/environments
```
Beispielausgabe:

In der Ausgabe des obigen Befehls sehen Sie eine Liste der zu der jeweiligen Organisation gehörenden Umgebungen, die auf den Message Processor geladen werden. Wenn beispielsweise die Umgebungen preprod und test auf den Message Processor geladen werden, erhalten Sie die folgende Ausgabe:

[ "preprod", "test" ]
Wenn die spezifische Umgebung, in der Sie eine Trace-Sitzung erstellen möchten, z. B. "dev", als Teil des obigen Befehls aufgeführt wird, fahren Sie mit den Einträgen veralteter Nachrichtenprozessoren fort.
Wenn die spezifische Umgebung, sagen Sie "dev", nicht als Teil des obigen Befehls aufgelistet wird, prüfen Sie /opt/apigee/var/log/edge-message-processor/logs/system.log und /opt/apigee/var/log/edge-message-processor/logs/startupruntimeerrors.log auf den Message Processorn auf Fehler beim Laden der Umgebungen.
Es können viele verschiedene Fehler auftreten, die zu Fehlern beim Laden einer Umgebung auf dem Message Processor führen können. Die Lösung hängt davon ab, welcher Fehler aufgetreten ist.

Auflösung

Die Umgebung kann aus vielen Gründen nicht in Message Processor geladen werden. In diesem Abschnitt werden einige mögliche Ursachen dafür aufgeführt und erklärt, wie Sie das Problem beheben können.

Wenn im Message Processor-Protokoll einer der folgenden Fehler angezeigt wird, liegt ein Problem mit den Zertifikaten/Schlüsseln vor, die dem angegebenen Keystore/Truststore in der angegebenen Umgebung hinzugefügt wurden.

Fehler 1: java.security.KeyStoreException: Eigenes Zertifikat kann nicht überschrieben werden

2018-01-30 12:04:38,248 pool-47-thread-4 ERROR MESSAGING.RUNTIME - AbstractConfigurator.propagateEvent() : Error while handling the update for the Configurator 
com.apigee.kernel.exceptions.spi.UncheckedException: Failed to add certificate : mycert in key store : mytruststore in environment : test
at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:156) ~[config-entities-1.0.0.jar:na] 
at com.apigee.entities.configurators.KeyStore.handleUpdate(KeyStore.java:101) ~[config-entities-1.0.0.jar:na] 
at com.apigee.entities.AbstractConfigurator.propagateEvent(AbstractConfigurator.java:85) ~[config-entities-1.0.0.jar:na] 
at com.apigee.messaging.runtime.Environment.handleUpdate(Environment.java:238) [message-processor-1.0.0.jar:na] 
… 
Caused by: java.security.KeyStoreException: Cannot overwrite own certificate 
at com.sun.crypto.provider.JceKeyStore.engineSetCertificateEntry(JceKeyStore.java:355) ~[sunjce_provider.jar:1.8.0_151] 
at java.security.KeyStore.setCertificateEntry(KeyStore.java:1201) ~[na:1.8.0_151] 
at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:153) ~[config-entities-1.0.0.jar:na]
... 20 common frames omitted
2018-01-30 12:04:38,250 pool-47-thread-4 ERROR MESSAGING.RUNTIME - AbstractConfigurator.rollbackTransaction() : Error in processing the changes : Unknown resource type cert

Fehler 2: java.security.KeyStoreException: Geheimer Schlüssel kann nicht überschrieben werden

2017-11-01 03:28:47,560 pool-21-thread-7 ERROR MESSAGING.RUNTIME - AbstractConfigurator.propagateEvent() : Error while handling the update for the Configurator 
com.apigee.kernel.exceptions.spi.UncheckedException: Failed to add certificate : mstore in key store : myTruststore in environment : dev 
at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:156) ~[config-entities-1.0.0.jar:na] 
at com.apigee.entities.configurators.KeyStore.handleUpdate(KeyStore.java:101) ~[config-entities-1.0.0.jar:na] 
... 
Caused by: java.security.KeyStoreException: Cannot overwrite secret key 
at com.sun.crypto.provider.JceKeyStore.engineSetCertificateEntry(JceKeyStore.java:354) ~[sunjce_provider.jar:1.8.0_144] 
at java.security.KeyStore.setCertificateEntry(KeyStore.java:1201) ~[na:1.8.0_144] 
at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:153) ~[config-entities-1.0.0.jar:na] 
... 20 common frames omitted 

2017-11-01 03:28:47,562 pool-21-thread-7 ERROR MESSAGING.RUNTIME - AbstractConfigurator.rollbackTransaction() : Error in processing the changes : Unknown resource type cert

Rufen Sie mithilfe des folgenden Verwaltungs-API-Aufrufs die Details zum Schlüsselspeicher/Vertrauensspeicher ab, der in der im vorherigen Schritt angezeigten Fehlermeldung angegeben wurde:

curl -v "http://<management-IPaddress>:8080/v1/organizations/<org-name>/environments/<env-name>/keystores/myTruststore" -u <user>

Beispielausgabe:

{ 
"certs": [ 
"mycert", 
"mycert-new" 
], 
"keys": [ 
"mycert" 
], 
"name": "myTruststore" 
}

Die Beispielausgabe zeigt, dass im Truststore myTruststore zwei Zertifikate und ein Schlüssel vorhanden sind. Der Truststore enthält in der Regel keinen Schlüssel. Ist dies der Fall, ist es besser, ein einzelnes Zertifikat und einen Schlüssel zu verwenden.

Rufen Sie die Details zu den beiden Zertifikaten mithilfe der folgenden API ab:

curl -s http://<management-IPaddress>:8080/v1/runtime/organizations/<org-name>/environments/<env-name>/keystores/<keystore-name>/certs/<cert-name>

Überprüfen Sie das Ablaufdatum jedes Zertifikats und ermitteln Sie, welches abgelaufene/ältere Zertifikat ist.
Löschen Sie das abgelaufene oder unerwünschte Zertifikat aus dem Truststore „myTruststore“.

Wenn das Problem weiterhin besteht oder ein anderer Fehler als der in Schritt 1 oben genannte Fehler auftritt, lesen Sie den Artikel Diagnoseinformationen müssen erfasst werden.

Ursache: Veraltete Einträge des Nachrichtenprozessors ODER Nachrichtenprozessoren nicht erreichbar

Diagnose

Wenn die Edge-Benutzeroberfläche lange dauert und die Trace-Sitzung nicht erstellt werden kann, gibt es einige mögliche Ursachen dafür:
1. Der Verwaltungsserver verweist möglicherweise auf nicht vorhandene (veraltete) Nachrichtenprozessoren.
2. Der/die Message Processor(e) wurde(n) angehalten oder ist nicht mehr erreichbar
3. Die Arbeitsspeicher-/CPU-Auslastung der Message Processors ist hoch
Prüfen Sie die /opt/apigee/var/log/edge-management-server/logs/system.log-Protokolle des Management Servers auf Fehler während der Erstellung der Trace-/Debug-Sitzung.

Während der Erstellung der Trace-/Debug-Sitzung wird möglicherweise eine Fehlermeldung wie „Server <UUID> is not up or reachable“ angezeigt, wie unten dargestellt:

2017-12-27 07:42:38,975 org:cocacola env:prod qtp2007599722-222063 INFO DISTRIBUTION - DebugSessionAPI.createDebugSession() : server 458b5910-2646-441c-a6e2-428b6d84e021 is either not up or reachable, skipping the server

Danach folgt ein weiterer Fehler „Zeitüberschreitung bei der Verbindung“, wie unten dargestellt:

2017-12-27 07:44:46.000 UTC org:cocacola env:prod qtp2007599722-222063 ERROR DISTRIBUTION - DebugSessionAPI.createDebugSession() : createDebugSession : Unable to connect to the server with UUID {}, skipping it458b5910-2646-441c-a6e2-428b6d84e021 org.apache.http.conn.HttpHostConnectException: Connect to 192.168.101.7:8080 [/192.168.101.7] failed: Connection timed out (Connection timed out) at org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:140) ~[httpclient-4.3.5.jar:4.3.5] at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:318) ~[httpclient-4.3.5.jar:4.3.5] at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:363) ~[httpclient-4.3.5.jar:4.3.5] at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:219) ~[httpclient-4.3.5.jar:4.3.5] 
…<snipped>
Caused by: java.net.ConnectException: Connection timed out (Connection timed out) at java.net.PlainSocketImpl.socketConnect(Native Method) ~[na:1.8.0_144] at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) ~[na:1.8.0_144]
…<snipped>

Diese beiden Fehler können durch bestimmte Message Processor(s) verursacht werden:
1. Veraltet (nicht mehr vorhanden)
2. Nicht erreichbar/aus irgendeinem Grund nicht erreichbar
Folgen Sie der entsprechenden Lösung für das jeweilige Szenario.

Auflösung

Szenario 1 : Nachrichtenprozessor(e) sind veraltet (nicht vorhanden)

Rufen Sie mithilfe der folgenden Verwaltungs-API eine Liste der Message Processor ab:

curl -u <sysadmin> "http://<management-server-host>:8080/v1/servers?pod=<podName>&regions=<regionName>"

Notieren Sie sich die IP-Adresse oder den Hostnamen, die bzw. die den UUIDs der Message Processor entsprechen, die in der Fehlermeldung in den Management Server-Protokollen erwähnt werden (Schritt 3 unter „Diagnose“ oben). Überprüfen Sie mithilfe einer der folgenden Methoden, ob es sich um gültige Message Processor handelt:
1. Neuestes Einrichtungsdiagramm der Private Cloud-Topologie
2. Aktuelle Edgeserver-IP-Adresse – Tabelle für die Zuordnung des Hostnamens
Wenn Sie feststellen, dass es sich um gültige Nachrichtenverarbeiter handelt, fahren Sie mit Szenario 2 : Nachrichtenverarbeiter sind nicht erreichbar fort.

Löschen Sie die veralteten (nicht vorhandenen) Message Processor mithilfe der folgenden Verwaltungs-APIs:

Heben Sie die Registrierung von Message Processor für die Umgebungen der Organisation auf:

curl -X POST http://<management-server-host>:8080/v1/o/<orgName>/e/<envName>/servers -d "uuid={uuid}&region=<regionName>&pod=<podName}&action=remove"

Registrierung des Servertyps aufheben:

curl http://<management-server-host>:8080/v1/servers -X POST -d "type={message-processor}&region=<regionName>&pod=<podName>&uuid=<uuid>&action=remove"

Löschen Sie den Server:

curl http://<management-ip>:8080/v1/servers/<uuid> -X DELETE

Wiederholen Sie Schritt 3, wenn das Problem auch in anderen Umgebungen Ihrer Organisation auftritt.

Szenario 2: Nachrichtenverarbeiter sind nicht erreichbar

Melden Sie sich bei jedem der Message Processor an, indem Sie die IP-Adressen/Hostnamen anhand der UUIDs ermitteln, die in der Fehlermeldung in den Management Server-Protokollen beobachtet werden.

Starten Sie den Message Processor neu:

/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

Prüfen Sie noch einmal, ob Sie die Trace-Sitzung erstellen können. Wenn das Problem weiterhin besteht, lesen Sie den Abschnitt Diagnoseinformationen müssen erfasst werden.

Ursache: Problem mit hoher Ressourcenauslastung

Diagnose

Melden Sie sich bei jedem der Message Processor an und prüfen Sie, ob eine hohe Auslastung von Ressourcen wie CPU, Arbeitsspeicher oder Last vorliegt. Auf Unix-basierten Betriebssystemen können Sie den Befehl top verwenden, um Informationen zur Ressourcenauslastung des Message Processor-Prozesses abzurufen:
```
top
```
Wenn die Ressourcen der Nachrichtenprozessoren nicht stark ausgelastet sind, fahren Sie mit Diagnoseinformationen müssen fort.
Wenn die CPU- oder Speicherauslastung des Message Processor bzw. die Message Processor hoch ist, reagiert der Message Processor möglicherweise nicht rechtzeitig auf dem Management Server. Dies verhindert schließlich, dass Sie eine Trace-Sitzung erstellen können.
1. Wenn ein Message Processor eine hohe CPU-Auslastung aufweist, generieren Sie mit dem folgenden Befehl alle 30 Sekunden drei Thread-Dumps:
```
sudo <JAVA_HOME>/bin/jstack -l <pid> > <filename>
```
2. Wenn ein Message Processor eine hohe Arbeitsspeichernutzung hat, generieren Sie mit dem folgenden Befehl einen Heap-Dump:
```
sudo -u apigee <JAVA_HOME>/bin/jmap -dump:live,format=b,file=<filename> <pid>
```
3. Zu Auflösung wechseln.

Auflösung

Starten Sie den Message Processor mit dem folgenden Befehl neu. Dies sollte die CPU- und Arbeitsspeichernutzung reduzieren:
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```
Überwachen Sie die API-Aufrufe und prüfen Sie, ob das Problem weiterhin besteht.
Wenden Sie sich an den Apigee Edge-Support und geben Sie die Thread-Dumps, Heap-Dumps und Nachrichtenprozessorprotokolle (/opt/apigee/var/log/edge-message-processor/logs/system.log)) an, damit das Team die Ursache für die hohe CPU-/Arbeitsspeichernutzung untersuchen kann.

Ursache: Der API-Proxy wurde auf einem oder mehreren Message Processorn nicht bereitgestellt

In seltenen Fällen kann ein API-Proxy nicht auf einem oder mehreren Message Processorn bereitgestellt werden. Dies liegt vor allem an einer fehlenden Ereignisbenachrichtigung vom Verwaltungsserver an den Message Processor bei der Bereitstellung des spezifischen API-Proxys. In diesem Fall können Sie die Trace-Sitzung auch nicht in der Edge-Benutzeroberfläche erstellen.

Diagnose

Melden Sie sich bei jedem der Message Processor an und prüfen Sie mit dem folgenden Befehl, ob die spezifische Version des API-Proxys bereitgestellt wurde:
```
curl -v localhost:8082/v1/runtime/organizations/<orgname>/environments/<envname>/apis/<apiname>/revisions
```
Beispielausgabe:

Sie sehen die Liste der Überarbeitungen als Ausgabe des obigen Befehls. Wenn beispielsweise Überarbeitung 12 bereitgestellt ist, sehen Sie die Ausgabe so:

[ "12" ]
Wenn die spezifische Version des API-Proxys nicht als Ausgabe des in Schritt 1 oben genannten Befehls angezeigt wird, starten Sie den jeweiligen Nachrichtenprozessor neu, wie unten im Abschnitt Lösung beschrieben.
Wiederholen Sie die Schritte 1 bis 2 für alle Message Processor.
Wenn die spezifische Version des API-Proxys auf allen Message Processorn bereitgestellt wird, ist dies nicht die Ursache für dieses Problem. Gehen Sie zu Diagnoseinformationen müssen erfasst werden.

Auflösung

Starten Sie die spezifischen Message Processor(e) neu, auf denen die spezifische Version des API-Proxys nicht bereitgestellt wurde:
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```

Ursache: Problem mit der Edge-Benutzeroberfläche

Diagnose

Prüfen Sie die Protokolle /opt/apigee/var/log/edge-ui/application.log und /opt/apigee/var/log/edge-ui/edge-ui.log der Edge-Benutzeroberfläche, um festzustellen, ob Fehler vorliegen.
Wenden Sie sich an den Apigee Edge-Support und geben Sie diese Dateien zur weiteren Untersuchung frei.

Diagnoseinformationen müssen erfasst werden

Wenn das Problem trotz Befolgen der obigen Anweisungen weiterhin besteht, stellen Sie die folgenden Diagnoseinformationen zusammen. Kontaktieren Sie sie und geben Sie sie für den Apigee Edge-Support frei:

Ausgabe des Befehls:

curl -v <management-server-host>:8080/v1/runtime/organizations/<org-name>/environments/<env-name>/apis/<apiproxy-name>/revisions/<revision-number>/debugsessions -u <user>

Protokoll des Verwaltungsservers

/opt/apigee/var/log/edge-management-server/logs/system.log.

Message Processor-Protokolle

/opt/apigee/var/log/edge-message-processor/logs/system.log.

Ausgabe der telnet/nc-Befehle vom Management-Server an den Message Processor:
```
telnet <MessageProcessor_IP> 8082
nc -vz <MessageProcessor_IP> 8082
```
Ausgabe des folgenden netstat-Befehls auf den Message Processor(s):
```
netstat -an > netstat.txt
```
Wenn es ein Problem mit der Edge-Benutzeroberfläche ist, geben Sie die Edge-UI-Protokolle /opt/apigee/var/log/edge-ui/application.log und /opt/apigee/var/log/edge-ui/edge-ui.log. an
Details zu den Abschnitten in diesem Playbook und andere Informationen, die uns helfen könnten, dieses Problem zügig zu lösen.