Fehler bei der Konfiguration des Bereitstellungsfehlers

Sie lesen gerade die Dokumentation zu Apigee Edge.
Zur Dokumentation zuApigee X wechseln.
info

Symptom

Die Bereitstellung von API-Proxy- oder Shared Flow-Revisionen über die Edge-Benutzeroberfläche oder die Management API schlägt mit dem Fehler Configuration failed (Konfiguration fehlgeschlagen) fehl.

Fehlermeldung

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

The revision is deployed, but traffic cannot flow.
com.apigee.kernel.exceptions.spi.UncheckedException{ code = application.bootstrap.FailedToConfigure, message = Configuration failed, associated contexts = []}

Screenshot einer Beispielfehlermeldung in der Edge-Benutzeroberfläche:

Mögliche Ursachen

Die Bereitstellung eines API-Proxys kann aus vielen verschiedenen Gründen mit dem Fehler „Configuration failed“ (Konfiguration fehlgeschlagen) fehlschlagen. In der folgenden Tabelle sind einige häufig beobachtete Ursachen aufgeführt, die zu diesem Fehler führen :

Ursache Beschreibung Anleitungen zur Fehlerbehebung gelten für
Fehlende Java-Klasse in der JavaCallout-Richtlinie In der JAR-Datei, auf die in der JavaCallout-Richtlinie verwiesen wird, fehlt eine Java-Klasse. Edge Private Cloud-Nutzer
Falsche Operanden in Bedingungen im Condition Flow verwendet Die auf einer oder beiden Seiten der Operatoren in den Bedingungen verwendeten Operanden/Ausdrücke sind ungültig.
Ungültiger Hostname in der MessageLogging-Richtlinie Der in der MessageLogging-Richtlinie verwendete Hostname kann nicht aufgelöst werden oder enthält unerwünschte Sonderzeichen.
Ungültiger KeyValueMap-Name Die KeyValueMap ist in der KeyValueMapOperations-Richtlinie im API-Proxy ungültig oder leer.

Allgemeine Diagnoseschritte

  1. Rufen Sie den Bereitstellungsstatus für die spezifische Revision des API-Proxys ab, für den der Bereitstellungsfehler auftritt. Verwenden Sie dazu die folgende API:

    curl -v <management-server-host>:<port#>/v1/runtime/organizations/<org-name>/environments/<env-name>/apis/<apiproxy-name>/revisions/deployments -u <user>
    
  2. Hier ist eine Beispielausgabe der oben genannten API:

    "server" : [ { 
    "error" : "com.apigee.kernel.exceptions.spi.UncheckedException{ code = application.bootstrap.FailedToConfigure, message = Configuration failed, associated contexts = []}", 
    "status" : "error", 
    "type" : [ "message-processor" ], 
    "uUID" : "0a20926c-f4bf-401b-af84-05fd84b9f492" 
    }, { 
    "error" : "com.apigee.kernel.exceptions.spi.UncheckedException{ code = application.bootstrap.FailedToConfigure, message = Configuration failed, associated contexts = []}", 
    "status" : "error", 
    "type" : [ "message-processor" ], 
    "uUID" : "f2ee6ab4-a108-4465-a7ba-b56530d8e3fc" 
    }, { 
    "error" : "com.apigee.kernel.exceptions.spi.UncheckedException{ code = application.bootstrap.FailedToConfigure, message = Configuration failed, associated contexts = []}", 
    "status" : "error", 
    "type" : [ "message-processor" ], 
    "uUID" : "0f41991e-b310-4e77-aac5-5fdb150ef9f6" 
    },
    
  3. In der Ausgabe des Bereitstellungsstatus wird die Fehlermeldung "Configuration failed" (Konfiguration fehlgeschlagen) für jeden Message Processor angezeigt.

  4. Melden Sie sich bei einem der Message Processors an und prüfen Sie das Log /opt/apigee/var/log/edge-message-processor/logs/system.log. Prüfen Sie, ob bei der Bereitstellung des API-Proxys Fehler aufgetreten sind.

  5. Je nach Fehler/Ausnahme, der im Message Processor-Log beobachtet wird, müssen Sie die entsprechenden Schritte zur Fehlerbehebung und Auflösung des Problems ausführen.

  6. In den folgenden Abschnitten werden einige der am häufigsten beobachteten Ausnahmen beschrieben, die zum Bereitstellungsfehler "Configuration failed" (Konfiguration fehlgeschlagen) führen. Außerdem finden Sie Schritte zur Fehlerbehebung und Auflösung dieser Ausnahmen.

Ursache: Fehlende Java-Klasse in der JavaCallout-Richtlinie

Diagnose

  1. Wenn in den Message Processor-Logs während der Bereitstellung eines API-Proxys (DeployEvent) eine Ausnahme mit der Meldung "Failed to instantiate the JavaCallout Class" angezeigt wird, fahren Sie mit Schritt 2 fort. Andernfalls gehen Sie zu Falsche Operanden in Bedingungen im Condition Flow verwendet.
  2. Der Message Processor zeigt während der Bereitstellung des API-Proxys die folgende Ausnahme an:

    2017-10-10 05:02:42,330 Apigee-Main-5 ERROR MESSAGING.CONFIGURATION - MessageProcessorServiceImpl.configure() : error configuring config events [DeployEvent{organization='myorg', application='oauth2', applicationRevision='14', deploymentSpec=basepath=/;env=dev;, deploymentID=null}] 
    com.apigee.kernel.exceptions.spi.UncheckedException: Failed to instantiate the JavaCallout Class com.something.apigee.callout.crypto.main.SecretCallout 
    at com.apigee.steps.javacallout.JavaCalloutStepDefinition.newInstance(JavaCalloutStepDefinition.java:89) ~[javacallout-1.0.0.jar:na] 
    at com.apigee.messaging.runtime.StepDefinition.getStepDefinitionExecution(StepDefinition.java:230) ~[message-processor-1.0.0.jar:na] 
    
    <snipped>
    
  3. Die Fehlermeldung in der oben genannten Ausnahme gibt an, dass die JavaCallout-Klasse com.something.apigee.callout.crypto.main.SecretCallout nicht instanziiert werden konnte. Dieser Fehler tritt in der Regel auf, wenn die spezifische Klasse nicht in der JAR-Datei vorhanden ist, die in der JavaCallout-Richtlinie angegeben ist, oder in einer der abhängigen JAR-Dateien.

  4. Prüfen Sie die JAR-Datei, die alle Klassen des Pakets com.something.apigee.callout.crypto.main enthält, und bestätigen Sie, dass die spezifische Klasse com.something.apigee.callout.crypto.main.SecretCallout fehlt.

Auflösung

  1. Fügen Sie die fehlende Klasse der spezifischen JAR-Datei hinzu und laden Sie die JAR-Datei hoch.
  2. Stellen Sie den API-Proxy neu bereit.
  3. Im obigen Beispiel haben wir das Problem so behoben:
    1. Die fehlende Klasse com.something.apigee.callout.crypto.main.SecretCallout wurde der JAR-Datei hinzugefügt.
    2. Die aktualisierte JAR-Datei wurde hochgeladen und der API-Proxy wurde neu bereitgestellt.

Ursache: Falsche Operanden mit Operatoren im Condition Flow verwendet

Diagnose

  1. Wenn in den Message Processor-Logs während der Bereitstellung eines API-Proxys oder Shared Flows eine com.apigee.expressions.parser.ParseException angezeigt wird, wie in den folgenden Beispielmeldungen, fahren Sie mit Schritt 2 fort. Andernfalls gehen Sie zur nächsten Ursache: Ungültiger Hostname in der MessageLogging-Richtlinie.

    Beispiel für Fehlermeldung

    com.apigee.expressions.parser.ParseException: Both the operands for EQUALS expression should be data expressions
    
    
  2. Sehen wir uns ein Beispiel an, um zu verstehen, wie dieses Problem diagnostiziert wird.

    Beispiel : Operanden für den Ausdruck <Operator> müssen Datenausdrücke sein

  3. Der Message Processor zeigt während der Bereitstellung eines Shared Flows die folgende Ausnahme an:

    2017-11-23 09:11:04,498  Apigee-Main-6 ERROR MESSAGING.RUNTIME - AbstractConfigurator.loadXMLConfigurations() : Unable to Load default for path /organizations/myorg/apiproxies/Introspection/revisions/12/sharedflows/default
    2017-11-23 09:11:04,499  Apigee-Main-6 ERROR MESSAGING.RUNTIME - Application.sync() :  sync error for Introspection and revision 12
    2017-11-23 09:11:04,499  Apigee-Main-6 ERROR MESSAGING.RUNTIME - Application.sync() :  Actual Error
    com.apigee.expressions.parser.ParseException: Both the operands for EQUALS expression should be data expressions
        at com.apigee.expressions.parser.ExpressionParser.buildExpressionTree(ExpressionParser.java:337) ~[expressions-1.0.0.jar:na]
        at com.apigee.expressions.parser.ExpressionParser.parse(ExpressionParser.java:24) ~[expressions-1.0.0.jar:na]
        at com.apigee.expressions.parser.ExpressionParser.parseLogicExpression(ExpressionParser.java:28) ~[expressions-1.0.0.jar:na]
        at com.apigee.messaging.runtime.Step.getExpression(Step.java:67) ~[message-processor-1.0.0.jar:na]
        at com.apigee.messaging.runtime.Step.handleAdd(Step.java:58) ~[message-processor-1.0.0.jar:na]
        at com.apigee.messaging.runtime.SharedFlowRuntime.addStep(SharedFlowRuntime.java:81) ~[message-processor-1.0.0.jar:na]  <snipped>
    
  4. Die Fehlermeldung in der ParseException – "Both the operands for EQUALS expression should be data expressions" weist auf ein Problem mit einer Bedingung hin, die den Operator „gleich“ (=), „ungleich“ (!=) oder „beginnt mit“ (=|) enthält.

  5. Sehen Sie sich die Bedingungen in allen Condition Flows an, die den in der Fehlermeldung genannten Operator enthalten, und prüfen Sie, ob eines der folgenden Probleme vorliegt:

    1. Die Ausdrücke auf beiden Seiten des Operators sind vom selben Typ. Wenn Sie beispielsweise eine Stringvariable auf der linken Seite des Operators haben, muss auf der rechten Seite eine andere Stringvariable oder ein Stringwert stehen.
    2. Zwischen den Operatoren werden gültige Variablen verwendet.
    3. Zwischen dem Operator und jedem der Ausdrücke befindet sich ein Leerzeichen.

  6. Wenn eines der oben genannten Kriterien nicht erfüllt ist, erhalten Sie die ParseException "Both the operands for EQUALS expression should be data expressions" (Beide Operanden für den Ausdruck EQUALS müssen Datenausdrücke sein).

  7. Sehen wir uns ein Beispiel an, um dieses Problem zu verstehen. Hier ist eine Beispiel-Fehlerbedingung:

    <Condition>
               (fault.name = "invalid_access_token") or(fault.name = "ApiKeyNotApproved")
    </Condition>
    
  8. In diesem Beispiel ist kein Leerzeichen zwischen dem Operator „or“ und der nächsten Bedingung. Wenn die zweite Bedingung geparst wird, wird der erste Ausdruck also als "or(fault.name" für den Operator EQUALS verwendet. Dies ist kein gültiger Variablenname und wird daher nicht als gültiger Datenausdruck behandelt. Folglich erhalten Sie diese Ausnahme:

    com.apigee.expressions.parser.ParseException: Both the operands for EQUALS expression should be data expressions
    
    

Auflösung

  1. Achten Sie darauf, dass auf beiden Seiten der Operatoren immer korrekte Datenausdrücke stehen.
  2. Im oben genannten Beispiel bestand die Lösung darin, nach dem Operator „or“ ein Leerzeichen einzufügen, wie im Code-Snippet beschrieben:

    <Condition>
               (fault.name = "invalid_access_token") or (fault.name = "ApiKeyNotApproved")
    </Condition>
    
    

Ungültiger Hostname in der MessageLogging-Richtlinie

Diagnose

  1. Wenn in den Message Processor-Logs während der Bereitstellung eines API-Proxys oder Shared Flows eine Ausnahme mit der Meldung "Invalid HostName" (Ungültiger Hostname) angezeigt wird, fahren Sie mit Schritt 2 fort. Andernfalls gehen Sie zur nächsten Ursache: Ungültiger KeyValueMap-Name.

    com.apigee.rest.framework.ValidationException: Invalid syslog config: Invalid HostName 'splunkprod.myorg.com/' for Syslog handler
    
  2. Sehen wir uns die beiden folgenden Beispiele an, um zu verstehen, wie Sie dieses Problem beheben können.

Beispiel 1: Hostname mit unerwünschtem Sonderzeichen

  1. Der Message Processor zeigt während der Bereitstellung des API-Proxys die folgende Ausnahme an:

      2018-01-20 02:12:13,535 Apigee-Main-3 ERROR MESSAGING.CONFIGURATION - MessageProcessorServiceImpl.configure() : error configuring config events [DeployEvent{organization='myorg', application='providersearch', applicationRevision='4', deploymentSpec=basepath=/;env=prod;, deploymentID=null}] 
      com.apigee.rest.framework.ValidationException: Invalid syslog config: Invalid HostName 'splunkprod.myorg.com/' for Syslog handler 
      at com.apigee.messaging.runtime.destinations.SyslogDestination.<init>(SyslogDestination.java:44) ~[message-processor-1.0.0.jar:na] 
      at com.apigee.messaging.runtime.destinations.SysLoggerFactory.getInstance(SysLoggerFactory.java:39) ~[message-processor-1.0.0.jar:na]
      at com.apigee.messaging.runtime.destinations.DestinationRegistry.newDestination(DestinationRegistry.java:44) ~[message-processor-1.0.0.jar:na] 
      ...<snipped>
    
  2. Die obige Ausnahme zeigt, dass die Bereitstellung aufgrund von "Invalid HostName '<hostname>' for Syslog handler" (Ungültiger Hostname „<hostname>“ für Syslog-Handler) fehlschlägt. Dies weist darauf hin, dass der in der MessageLogging -Richtlinie verwendete Hostname ungültig ist.

  3. Wenn Sie die Ausnahme im Message Processor-Log sorgfältig prüfen, sehen Sie, dass am Ende des Hostnamens ein unerwünschtes Sonderzeichen „/“ steht 'splunkprod.myorg.com/'.

  4. Dieses unerwünschte Sonderzeichen war die Ursache für den Bereitstellungsfehler.

Auflösung

  1. Ändern Sie die MessageLogging-Richtlinie, um alle unerwünschten Sonderzeichen zu entfernen und das Problem zu beheben.
  2. Im obigen Beispiel wurde das Sonderzeichen „/“ aus der MessageLogging-Richtlinie entfernt. Dadurch wurde das Problem behoben.

Beispiel 2: Hostname kann nicht aufgelöst werden

  1. Das Message Processor-Log enthielt einige Zeilen, die zeigen, dass das Bereitstellungsereignis für einen API-Proxy ausgelöst wurde. Darauf folgt eine Ausnahme, die während der Bereitstellung des API-Proxys auftritt:

    2017-12-22 00:13:49,057 Apigee-Main-87446 INFO MESSAGING.CONFIGURATION - MessageProcessorServiceImpl.configure() : configuring [DeployEvent{organization='myorg', application='myapi', applicationRevision='42', deploymentSpec=basepath=/;env=dev;, deploymentID=null}] 
    
    2017-12-22 00:13:49,318 Apigee-Main-87446 ERROR c.a.p.h.d.DNSCachedAddress - DNSCachedAddress.refresh() : Unable to resolve host : input-prd.cloud.splunk.com: Name or service not known 
    
    2017-12-22 00:13:49,323 Apigee-Main-87446 ERROR MESSAGING.RUNTIME - AbstractConfigurator.handleUpdate() : Fatal error deploying proxy: {} 
    com.apigee.rest.framework.ValidationException: Invalid syslog config: Invalid HostName 'input-prd.cloud.splunk.com' for Syslog handler 
    at com.apigee.messaging.runtime.destinations.SyslogDestination.<init>(SyslogDestination.java:44) ~[message-processor-1.0.0.jar:na] 
    at com.apigee.messaging.runtime.destinations.SysLoggerFactory.getInstance(SysLoggerFactory.java:39) ~[message-processor-1.0.0.jar:na] 
    at com.apigee.messaging.runtime.destinations.DestinationRegistry.newDestination(DestinationRegistry.java:44) ~[message-processor-1.0.0.jar:na] 
    at com.apigee.steps.messagelogging.MessageLoggingStepDefinition.populateDestinations(MessageLoggingStepDefinition.java:118) ~[message-logging-1.0.0.jar:na] 
    at com.apigee.steps.messagelogging.MessageLoggingStepDefinition.handleAdd(MessageLoggingStepDefinition.java:99) ~[message-logging-1.0.0.jar:na] 
    
    <snipped> 
    
  2. Die obige Ausnahme zeigt, dass die Bereitstellung aufgrund von "Invalid HostName '<hostname>' for Syslog handler" (Ungültiger Hostname „<hostname>“ für Syslog-Handler) fehlschlägt.

  3. Wenn Sie die Zeile über der Ausnahme lesen, sehen Sie, dass der Message Processor den in der MessageLogging-Richtlinie angegebenen Hostnamen 'input-prd.cloud.splunk.com' nicht auflösen kann.

  4. Um dies zu bestätigen, können Sie versuchen, eine Telnet-Verbindung zum Hostnamen und zur Portnummer herzustellen, die in der MessageLogging-Richtlinie verwendet werden.

    1. Prüfen Sie die MessageLogging-Richtlinie in der spezifischen Revision des API-Proxys und bestätigen Sie den verwendeten Hostnamen und die Portnummer. Im obigen Beispiel lautet der API-Proxy-Name „myapi“ und die Revision „42“.

      MessageLogging-Richtlinie

        <MessageLogging async="false" continueOnError="false" enabled="true" name="Log-To-Splunk">
            <DisplayName>Log-To-Splunk</DisplayName>
            <Syslog>
                <Message>Message.id = {request.header.id}</Message>
                <Host>input-prd.cloud.splunk.com</Host>
                <Port>2900</Port>
                <Protocol>TCP</Protocol>
                <SSLInfo>
                    <Enabled>true</Enabled>
                </SSLInfo>
            </Syslog>
        </MessageLogging>
      
    2. Stellen Sie eine Telnet-Verbindung zum Host mit dem spezifischen Port her. In diesem Beispiel haben wir Telnet ausprobiert und denselben Fehler wie im Message Processor-Log erhalten:

      telnet input-prd.cloud.splunk.com 2900 
      telnet: input-prd.cloud.splunk.com: Name or service not known 
      input-prd.cloud.splunk.com: Host name lookup failure
      
  5. Das hat eindeutig bewiesen, dass der Hostname nicht aufgelöst werden kann.

Auflösung

  1. Ändern Sie die MessageLogging-Richtlinie, um den gültigen Hostnamen zu verwenden.

Wenn das Problem weiterhin besteht, lesen Sie unten den Abschnitt Erfassen von Diagnoseinformationen erforderlich.

Ursache: Ungültiger KeyValueMap-Name

Diagnose

  1. Wenn in den Message Processor-Logs während der Bereitstellung eines API-Proxys oder Shared Flows eine Ausnahme mit der Meldung "KeyValueMap name is invalid" (KeyValueMap-Name ist ungültig) angezeigt wird, fahren Sie mit Schritt 2 fort. Andernfalls gehen Sie zu Erfassen von Diagnoseinformationen erforderlich.

    com.apigee.rest.framework.ValidationException: Invalid syslog config: Invalid HostName 'splunkprod.myorg.com/' for Syslog handler
    
  2. Sehen wir uns ein Beispiel an, um zu verstehen, wie Sie dieses Problem beheben können.

  3. Beispiel für ein Message Processor-Log mit der Ausnahme „KeyValueMap name is invalid“ (KeyValueMap-Name ist ungültig), die zu einem Fehler bei der Bereitstellung des API-Proxys führt

    2018-02-27 14:14:50,318  Apigee-Main-6 ERROR MESSAGING.RUNTIME - AbstractConfigurator.handleUpdate() : Fatal error deploying proxy: {}
    com.apigee.keyvaluemap.KeyValueMapApiException: KeyValueMap name  is invalid
            at com.apigee.keyvaluemap.service.legacy.KeyValueMapServiceImpl.validateMapName(KeyValueMapServiceImpl.java:125) ~[keyvaluemap-1.0.0.jar:na]
            at com.apigee.keyvaluemap.service.legacy.KeyValueMapServiceImpl.createOrUpdateKeyValueMap(KeyValueMapServiceImpl.java:185) ~[keyvaluemap-1.0.0.jar:na]
            at com.apigee.steps.keyvaluemapoperations.KeyValueMapOperationsStepDefinition.digest(KeyValueMapOperationsStepDefinition.java:180) ~[keyvaluemap-operations-1.0.0.jar:na]
            at com.apigee.steps.keyvaluemapoperations.KeyValueMapOperationsStepDefinition.handleAdd(KeyValueMapOperationsStepDefinition.java:197) ~[keyvaluemap-operations-1.0.0.jar:na]
            at com.apigee.entities.AbstractConfigurator.handleUpdate(AbstractConfigurator.java:130) [config-entities-1.0.0.jar:na]
            at com.apigee.messaging.runtime.Application.handleUpdate(Application.java:229) [message-processor-1.0.0.jar:na]
    
    2018-02-27 14:14:50,344  Apigee-Main-6 ERROR BOOTSTRAP - RuntimeConfigurationServiceImpl.dispatchToListeners() : RuntimeConfigurationServiceImpl.dispatchToListeners : Error occurred while dispatching the request DeployEvent{organization='myorg', application='CustomerAPI', applicationRevision='1', deploymentSpec=basepath=/;env=test;, deploymentID=null} to com.apigee.application.bootstrap.listeners.MessageProcessorBootstrapListener@5009d06e
    com.apigee.keyvaluemap.KeyValueMapApiException: KeyValueMap name  is invalid
            at com.apigee.keyvaluemap.service.legacy.KeyValueMapServiceImpl.validateMapName(KeyValueMapServiceImpl.java:125) ~[keyvaluemap-1.0.0.jar:na]
            at com.apigee.keyvaluemap.service.legacy.KeyValueMapServiceImpl.createOrUpdateKeyValueMap(KeyValueMapServiceImpl.java:185) ~[keyvaluemap-1.0.0.jar:na]
            at com.apigee.steps.keyvaluemapoperations.KeyValueMapOperationsStepDefinition.digest(KeyValueMapOperationsStepDefinition.java:180) ~[keyvaluemap-operations-1.0.0.jar:na]
            at com.apigee.steps.keyvaluemapoperations.KeyValueMapOperationsStepDefinition.handleAdd(KeyValueMapOperationsStepDefinition.java:197) ~[keyvaluemap-operations-1.0.0.jar:na]
            at com.apigee.entities.AbstractConfigurator.handleUpdate(AbstractConfigurator.java:130) ~[config-entities-1.0.0.jar:na]
            at com.apigee.messaging.runtime.Application.handleUpdate(Application.java:229) ~[message-processor-1.0.0.jar:na]
    
  4. Die zweite Ausnahme oben gibt an, dass der Bereitstellungsfehler für API-Proxy: CustomerAPI, Revision: 1 aufgetreten ist.

  5. Wenn Sie den Stacktrace prüfen, sehen Sie, dass der Fehler beim Ausführen der KeyValueMapOperations-Richtlinie ausgelöst wird.

  6. Wenn Sie sich das API-Proxy-Bundle ansehen, sehen Sie, dass es eine KeyValueMapOperations-Richtlinie mit dem folgenden Code gibt:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <KeyValueMapOperations async="false" continueOnError="false" enabled="true" name="Pulling-Keys" mapIdentifier="">
     <DisplayName>Pulling Keys</DisplayName>
     <Properties/>
     <ExclusiveCache>false</ExclusiveCache>
    
    
  7. Wie oben zu sehen, enthält mapIdentifier, das den Namen der KeyValueMap angibt, einen leeren String. Der KeyValueMap-Name darf kein leerer String sein. Das war die Ursache für den Bereitstellungsfehler.

Auflösung

  1. Ändern Sie die KeyValueMapOperations-Richtlinie, um einen korrekten gültigen Namen für die KeyValueMap zu verwenden.
  2. Im obigen Beispiel haben wir das Problem behoben, indem wir die KeyValueMapOperations-Richtlinie so geändert haben, dass der KeyValueMap-Name „MyKeyValueMap“ lautet, wie unten gezeigt:

      <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
      <KeyValueMapOperations async="false" continueOnError="false" enabled="true" name="Pulling-Keys" mapIdentifier="MyKeyValueMap">
        <DisplayName>Pulling Keys</DisplayName>
        <Properties/>
        <ExclusiveCache>false</ExclusiveCache>
    

Erfassen von Diagnoseinformationen erforderlich

Wenn das Problem auch nach Befolgen der obigen Anweisungen weiterhin besteht, erfassen Sie die folgenden Diagnoseinformationen. Wenden Sie sich an den Apigee Edge-Support und geben Sie die erfassten Informationen an.

  1. Ausgabe des Befehls

    curl -v <management-server-host>:<port #>/v1/runtime/organizations/<org-name>/environments/<env-name>/apis/<apiproxy-name>/revisions/deployments -u <user>
    
  2. Message Processor-Logs

    /opt/apigee/var/log/edge-message-processor/logs/system.log
    
  3. Details zu den Abschnitten in diesem Playbook, die Sie ausprobiert haben, und alle anderen Informationen, die uns helfen, das Problem schnell zu beheben.