Best Practices für Google Cloud Apigee-Supportfälle

Sie lesen die Dokumentation zu Apigee X.
Apigee Edge-Dokumentation aufrufen

Wenn Sie im Supportfall detaillierte und erforderliche Informationen angeben, ist es für das Google Cloud Apigee-Supportteam leichter, Ihnen schnell und effizient zu antworten. Wenn in Ihrem Support kritische Details fehlen, müssen wir nach weiteren Informationen fragen, was unter Umständen mehrmals erforderlich ist. Dieser Vorgang dauert länger und kann zu Verzögerungen bei der Problembehebung führen. In diesem Best Practices-Leitfaden erfahren Sie, welche Informationen wir benötigt, um Ihren technischen Supportfall schneller bearbeiten zu können.

Problem beschreiben

Ein Problem sollte Informationen dazu enthalten, was passiert ist, was geschehen ist und wann und wie es aufgetreten ist. Ein guter Apigee-Supportfall sollte die folgenden wichtigen Informationen zu jedem Apigee-Produkt enthalten:

Schlüsselinformationen Beschreibung Apigee Cloud (Apigee on Google Cloud/Apigee Edge for Public Cloud) Apigee Edge for Private Cloud Apigee hybrid
Produkt Bestimmtes Apigee-Produkt, in dem das Problem auftritt, einschließlich Versionsinformationen, falls zutreffend
  • Version
  • Hybridversion
Problemdetails Klare und ausführliche Problembeschreibung, die das Problem zusammen mit der vollständigen Fehlermeldung beschreibt, falls vorhanden.
  • Fehlermeldung
  • Ausgabe des Debug-Tools
  • Schritte zum Reproduzieren des Problems
  • API-Anfrage/-Befehl abschließen
  • Fehlermeldung
  • Ausgabe des Debug-Tools
  • Schritte zum Reproduzieren des Problems
  • API-Anfrage/-Befehl abschließen
  • Diagnoseprotokolle der Komponente
  • Fehlermeldung
  • Ausgabe des Debug-Tools
  • Schritte zum Reproduzieren des Problems
  • API-Anfrage/-Befehl abschließen
  • Diagnoseprotokolle der Komponente
  • Cloud Monitoring-Messwerte
Zeit Der spezifische Zeitstempel für den Beginn und das Ende des Problems.
  • Datum, Uhrzeit und Zeitzone des Problems
  • Dauer des Problems
  • Datum, Uhrzeit und Zeitzone des Problems
  • Dauer des Problems
  • Datum, Uhrzeit und Zeitzone des Problems
  • Dauer des Problems
Setup Detaillierte Informationen, unter denen das Problem beobachtet wird.
  • Name der Organisation
  • Env-Name
  • Name des API-Proxys
  • Revision
  • Netzwerktopologie
  • Edge-Komponente schlägt fehl

In den folgenden Abschnitten sind diese Konzepte detaillierter beschrieben.

Produkt

Es gibt verschiedene Apigee-Produkte, Apigee Cloud (Apigee on Google Cloud/Apigee Edge on Public Cloud), Apigee Edge on Private Cloud und Apigee Hybrid. Wir benötigen daher genaue Informationen darüber, bei welchem Produkt das Problem auftritt.

Die folgende Tabelle enthält einige Beispiele für vollständige Informationen in der Spalte DOs und unvollständige Informationen in der Spalte DON'Ts:

DOs DON'Ts
Bereitstellung des API-Proxys OAuth2 ist in unserer Public Cloud-Organisation fehlgeschlagen.

Bereitstellung des API-Proxys fehlgeschlagen

(Wir müssen das Apigee-Produkt kennen, in dem das Problem auftritt.)

Die Installation ist mit dem folgenden Fehler unserer Edge Private Cloud-Version 4.50.00 fehlgeschlagen...

Die Installation bei der Einrichtung der Private Cloud ist fehlgeschlagen.

(Versionsinformationen fehlen)

Beim Zugriff auf Cassandra mit cqlsh in Apigee Hybrid Version 1.3 wird der folgende Fehler angezeigt...

Wir können nicht mit cqlsh auf Cassandra zugreifen.

(Informationen zur Hybridversion fehlen)

Problemdetails

Geben Sie genaue Informationen zum beobachteten Problem an, einschließlich der Fehlermeldung (falls vorhanden) und des erwarteten und tatsächlichen Verhaltens.

Die folgende Tabelle enthält einige Beispiele für vollständige Informationen in der Spalte DOs und unvollständige Informationen in der Spalte DON'Ts:

DOs DON'Ts

Neuer edgemicro-Proxy edgemicro_auth schlägt mit folgendem Fehler fehl:

{"error":"missing_authorization","error_description":"Missing Authorization header"}

Neuer edgemicro-Proxy wurde heute nicht erstellt

(Der Proxyname ist unbekannt. Es ist nicht klar, ob der Proxy einen Fehler oder eine unerwartete Antwort zurückgibt.)

Unsere Clients erhalten bei Anfragen an den API-Proxy 500-Fehler mit der folgenden Fehlermeldung:

{"fault":{"faultstring":"Execution of JSReadResponse failed with error: Javascript runtime error: \"TypeError: Cannot read property \"content\" from undefined. (JSReadResponse.js:23)","detail":{"errorcode":"steps.javascript.ScriptExecutionFailed"}}}

Unsere Clients erhalten 500-Fehler, wenn sie Anfragen an den API-Proxy senden.

(Wenn Sie 500-Fehler einfach mitteilen, liefern wir Ihnen keine ausreichenden Informationen, um das Problem zu untersuchen. Wir müssen die tatsächliche Fehlermeldung und den tatsächlich aufgetretenen Fehlercode kennen.)

Zeit

Die Zeit ist sehr wichtig. Es ist wichtig, dass der Supporttechniker weiß, wann Sie das Problem erstmals bemerkt haben, wie lange es dauert und ob das Problem weiterhin auftritt.

Der Supporttechniker, der das Problem bearbeitet, befindet sich möglicherweise nicht in Ihrer Zeitzone. Daher erschweren relative Aussagen des Zeitraums die Diagnose des Problems. Es wird daher empfohlen, für das Datum und den Zeitstempel das ISO 8601-Format zu verwenden, um die genauen Zeitinformationen bereitzustellen, zu denen das Problem beobachtet wurde.

Die folgende Tabelle enthält einige Beispiele, die den genauen Zeitpunkt und die Dauer des Auftretens des Problems in der Spalte DOs und mehrdeutige oder unklare Informationen darüber, wann das Problem auftrat, in der Spalte DON'Ts zeigen:

DOs DON'Ts
Die große Anzahl von 503s wurde gestern zwischen dem 06.11.2019 um 17:30 Uhr (UTC) und dem 06.11.2017 um 17:35 Uhr (UTC -7) beobachtet...

Riesige Anzahl von 503s gestern um 17:30 Uhr beobachtet.

(Die Verwendung des implizierten Datums ist zwingend erforderlich. Außerdem ist unklar, in welcher Zeitzone das Problem beobachtet wurde.)

Starke Latenzen wurden bei den folgenden API-Proxys von 09.11.2020, 15:30 IST, bis zum 20.11.2019 um 18:10 IST beobachtet...

In der letzten Woche wurden bei einigen API-Proxys hohe Latenzen beobachtet.

Dabei ist nicht ersichtlich, an welchem Tag und zu welcher Uhrzeit dieses Problem in der letzten Woche aufgetreten ist.

Einrichtung

Wir benötigen genaue Angaben dazu, wo genau das Problem auftritt. Je nach verwendetem Produkt benötigen wir die folgenden Informationen:

  • Wenn Sie mit Apigee Cloud arbeiten, haben Sie möglicherweise mehrere Organisationen. Wir müssen die Organisation (und andere Details) kennen, bei der das Problem zu beobachten ist:
    • Organisations- und Umgebungsnamen
    • API-Proxyname und Revisionsnummern (bei API-Anfragefehlern)
  • Wenn Sie die Private Cloud verwenden, nutzen Sie möglicherweise eine der vielen unterstützten Installationstopologien. Wir müssen wissen, welche Topologie Sie verwenden, einschließlich der Details wie Anzahl der Rechenzentren und Knoten.
  • Wenn Sie Hybrid verwenden, verwenden Sie möglicherweise eine der vielen unterstützten Hybridplattformen und Installationstopologien. Wir müssen wissen, welche Hybridplattform und Topologie Sie verwenden, einschließlich der Details wie Anzahl der Rechenzentren und Knoten.

Die folgende Tabelle enthält einige Beispiele für vollständige Informationen in der Spalte DOs und unvollständige Informationen in der Spalte DON'Ts:

DOs DON'Ts

401 In Edge Public Cloud sind Fehler seit 06.11.2017 um 09:30 CST gestiegen.

Details der Edge-Einrichtung:

Die Details der fehlgeschlagenen API sind:
Org.-Namen: myorg
Envs: test
API-Proxy-Namen: myproxy
Überarbeitungsnummern: 3

Fehler:

{"fault":{"faultstring":"Failed to resolve API Key variable request.header.X-APP-API_KEY","detail":{"errorcode":"steps.oauth.v2.FailedToResolveAPIKey"}}}

401 Fehler sind gestiegen.

Er enthält keine Informationen über das verwendete Produkt, da das Problem beobachtet wird, sowie keine Konfigurationsdetails.

Starten Sie den Message Processor nicht in Edge Private Cloud Version 4.19.06 , nachdem Sie zusätzliche Gateway-Knoten hinzugefügt haben.

Diagnoseunabhängige Logs:
Die Nachrichtenverarbeiterlogs wurden angehängt.

Netzwerktopologie:
Die Datei network-topology.png hat die zusätzlichen Knoten angehängt.

Starten Sie den Message Processor nicht in Edge Private Cloud Version 4.19.06 , nachdem Sie zusätzliche Gateway-Knoten hinzugefügt haben.

Die Nachrichtenverarbeiterlogs und die Netzwerktopologie fehlen.

Debug schlägt mit dem folgenden Fehler in Apigee Hybrid 1.3 fehl

Fehler:

Error while Creating trace session for corp-apigwy-discovery, revision 3, environment dev.

Failed to create DebugSession {apigee-hybrid-123456 dev corp-apigwy-discovery 3 ca37384e-d3f4-4971-9adb-dcc36c392bb1}

Einrichtung von Apigee Hybrid:

  • Apigee Hybrid-Plattform:
    Anthos GKE On-Prem Version 1.4.0
  • Google Cloud-Projekt, Hybrid-Organisation und -Umgebung
    Google Cloud-Projekt-ID: apigee-hybrid-123456
    Apigee Hybrid org: apigee-hybrid-123456
    Apigee Hybrid env: dev
  • Details zum Kubernetes-Clusternamen:
    k8sCluster:
    Name: user-cluster-1
    Region: us-east1
  • Netzwerktopologie
    Hängt die Datei network-topology.png an.
Fehler bei Apigee Hybrid:

Nützliche Artefakte

Die Bereitstellung von Artefakten, die mit dem Problem zusammenhängen, beschleunigt die Problemlösung, da wir so das Verhalten besser nachvollziehen und analysieren können.

In diesem Abschnitt werden einige nützliche Artefakte beschrieben, die für alle Apigee-Produkte hilfreich sind:

Gängige Artefakte für alle Apigee-Produkte

Die folgenden Artefakte sind für alle Apigee-Produkte nützlich: Apigee Cloud (Apigee on Google Cloud/Apigee Edge on Public Cloud), Apigee Edge on Private Cloud und Apigee Hybrid:

Artefakt Beschreibung
Ausgabe des Debugging-Tools Die Ausgabe des Debug-Tools enthält detaillierte Informationen zu den API-Anfragen, die durch Apigee-Produkte fließen. Dies ist bei Laufzeitfehlern wie 4XX, 5XX und Latenzproblemen hilfreich.
Screenshots Screenshots vermitteln den Kontext des tatsächlichen Verhaltens oder beobachteten Fehlers. Sie ist hilfreich, wenn Fehler oder Probleme beobachtet werden, etwa in der Benutzeroberfläche oder in Analytics.
HAR (Http ARchive) HAR ist eine Datei, die von HTTP-Sitzungstools für die Behebung von Problemen mit der Benutzeroberfläche erfasst wird. Dies kann mit Browsern wie Chrome, Firefox oder Internet Explorer erfasst werden.
tcpdumps Das tcpdump-Tool erfasst TCP/IP-Pakete, die über das Netzwerk übertragen oder empfangen werden. Dies ist bei netzwerkbezogenen Problemen wie TLS-Handshake-Fehlern, 502-Fehlern und Latenzproblemen usw.

Zusätzliche Artefakte für Apigee Edge for Private Cloud

Für Apigee Edge for Private Cloud benötigen wir möglicherweise einige zusätzliche Artefakte, um die Problemdiagnose zu beschleunigen.

Artefakt Beschreibung
Netzwerktopologie Das Edge-Installationstopologiediagramm zur Beschreibung Ihrer privaten Cloud-Einrichtung, einschließlich aller Rechenzentren, Knoten und Komponenten, die auf jedem Knoten installiert sind.
Diagnoselogs für Edge-Komponenten Die Diagnoselogs für die jeweilige Apigee Edge-Komponente wie Message Processor, Router oder Cassandra.
Konfigurationsdatei für die Installation Dies ist die laute Konfigurationsdatei, die bei der Installation oder Aktualisierung von Apigee Edge verwendet wird.

Diese Datei ist nützlich, um zu überprüfen, ob alle Einstellungen korrekt sind, falls Installations- oder Migrationsprobleme auftreten.

Heap-Dumps Heap-Dumps sind Snapshots des Java-Speichervorgangs. Dies ist nützlich, wenn bei bestimmten Edge-Komponenten hohe Speichernutzung oder OutOfMemory-Fehler auftreten.
Thread-Dumps Ein Thread-Dump ist ein Snapshot aller Threads eines laufenden Java-Prozesses.

Dies ist sinnvoll, wenn mit bestimmten Edge-Komponenten hoher CPU- oder Last-Traffic beobachtet wird.

Zusätzliche Artefakte für Hybrid

Für Hybrid benötigen wir möglicherweise zusätzliche Artefakte, die eine schnellere Diagnose von Problemen ermöglichen.

Artefakt Beschreibung
Plattform von Apigee Hybrid Geben Sie eine der folgenden unterstützten Hybridplattformen an:
  • GKE
  • GKE On-Prem
  • AKS (Azure Kubernetes Service)
  • Amazon EKS
  • GKE on AWS
Apigee Hybrid und abhängige Komponentenversionen
  • Apigee Hybrid-CLI-Version:
    apigeectl-Version
  • Apigee Connect-Agent-Version:
    kubectl -n=apigee get pods -l app=apigee-connect-agent -o=json | jq '.items[].spec.containers[].image'
  • Apigee MART-Version:
    kubectl -n=apigee get pods -l app=apigee-mart -o=json | jq '.items[].spec.containers[].image'
  • Apigee Synchronizer-Version:
    kubectl -n=apigee get pods -l app=apigee-synchronizer -o=json | jq '.items[].spec.containers[].image'
  • Apigee Cassandra-Version:
    kubectl -n=apigee get pods -l app=apigee-cassandra -o=json | jq '.items[].spec.containers[].image'
  • Apigee-Laufzeitversion:
    kubectl -n=apigee get pods -l app=apigee-runtime -o=json | jq '.items[].spec.containers[].image'
  • Kubernetes-Befehlszeile und Serverversionen:
    kubectl-Version
  • Istio Befehlszeile und Serverversionen:
    istioctl-Version
Netzwerktopologie Das Apigee-Installationstopologiediagramm zur Beschreibung Ihrer Hybrideinrichtung mit allen Rechenzentren, Kubernetes-Clustern, Namespaces und Pods.
Überschreibt YAML-Datei Die Datei overrides.yaml, die in jedem Rechenzentrum zum Installieren der Apigee Hybrid-Laufzeitebene verwendet wird.
Status der Bereitstellung von Apigee Hybrid

Die Ausgabe der folgenden Befehle in jedem Rechenzentrum/Kubernetes-Cluster:

kubectl get pods -A
kubectl get services -A

Apigee Hybrid-Komponentenkomponenten

Geben Sie Links zu den Stackdriver-Logs für die Hybrid-Komponenten an ODER

Sie können die Protokolle der Apigee Hybrid-Komponenten mit den folgenden Befehlen in jedem Rechenzentrum/Kubernetes-Cluster abrufen und mit uns teilen:

kubectl -n {namespace} get pods
kubectl -n {namespace} logs {pod-name}

  • Apigee Connect-Agent-Logs:
    kubectl -n {namespace} get pods
    kubectl -n {namespace} logs {apigee-connect-agent-pod-name}
  • MART Logs:
    kubectl -n {namespace} get pods
    kubectl -n {namespace} logs {apigee-mart-pod-name}
  • Synchronizer Logs:
    kubectl -n {namespace} get pods
    kubectl -n {namespace} logs {synchronizer-pod-name}
  • Apigee Cassandra-Logs:
    kubectl -n {namespace} get pods
    kubectl -n {namespace} logs {apigee-cassandra-pod-name}
  • MP/Apigee-Laufzeitlogs (von allen Apigee-Laufzeit-Pods):
    kubectl -n {namespace} get pods
    kubectl -n {namespace} logs {apigee-runtime-pod-name}
Logs beschreiben

Detaillierte Informationen zum Pod.

Dies ist insbesondere dann hilfreich, wenn Probleme wie Pods auftreten, die im Status CrashLoopBackoff hängen bleiben.

kubectl -n apigee describe pod {pod-name}

Cloud Monitoring
  • Link zu Ihrem Messwert-Dashboard
  • Snapshots von Dashboards im Zusammenhang mit Cloud Monitoring-Messwerten.

Fallvorlagen und Beispielfälle

Dieser Abschnitt enthält Fallvorlagen und Beispielfälle für verschiedene Produkte gemäß den in diesem Dokument beschriebenen Best Practices:

Apigee Cloud

Vorlage

Dieser Abschnitt enthält eine Beispielvorlage für Apigee Cloud (Apigee on Google Cloud/Apigee Edge on Public Cloud).

Problem:

<Geben Sie eine detaillierte Beschreibung des Problems oder des beobachteten Verhaltens an. Geben Sie den Produktnamen und die Version an, falls zutreffend.>

Fehlermeldung:

<Geben Sie die vollständige angezeigte Fehlermeldung an (falls vorhanden)>

Problemstartzeit (ISO 8601-Format):

Problemendzeit (ISO 8601-Format):

Apigee-Einrichtungsdetails:
Org.-Namen:
Umg.-Namen:
API-Proxy-Namen:
Revisionsnummern:

Zu reproduzierende Schritte:

<Geben Sie nach Möglichkeit Schritte zum Reproduzieren des Problems an>

Diagnosedaten:

<Liste der angehängten Dateien>

Beispielfall

Dieser Abschnitt enthält einen Beispielfall für Apigee Cloud (Apigee on Google Cloud/Apigee Edge on Public Cloud).

Problem:

In der Public Cloud-Organisation werden viele 503-Dienstfehler nicht angezeigt. Können Sie sich das Problem genauer ansehen oder es beheben oder uns eine Lösung vorschlagen?

Fehlermeldung:

{"fault":{"faultstring":"The Service is temporarily available", "detail":{"errorcode":"messaging.adaptors.http.flow.ServiceUnavailable"}}}

Problemstartzeit (ISO 8601-Format): 2020-04-06:30 ISSST

Problemendzeit (ISO 8601-Format): Das Problem besteht weiterhin.

Edge-Cloud-Einrichtungsdetails:
Org.-Namen: myorg
Umg.-Namen: dev
API-Proxy-Namen: myproxy
Revisionsnummern: 3

Zu reproduzierende Schritte:

Führen Sie den folgenden curl-Befehl aus, um das Problem zu reproduzieren:

curl -X GET 'https://myorg-dev.apigee.net/v1/myproxy'

Diagnosedaten:

Ausgabe des Tools zur Fehlerbehebung (trace-503.xml)

Apigee Edge for Private Cloud

Vorlage

Dieser Abschnitt enthält eine Beispielvorlage für Apigee Edge for Private Cloud.

Problem:

<Geben Sie eine detaillierte Beschreibung des Problems oder des beobachteten Verhaltens an. Geben Sie den Produktnamen und die Version an, falls zutreffend.>

Fehlermeldung:

<Geben Sie die vollständige angezeigte Fehlermeldung an (falls vorhanden)>

Problemstartzeit (ISO 8601-Format):

Problemendzeit (ISO 8601-Format):

Details zur Einrichtung von Edge Private Cloud:

<Netzwerk-Topologie anhängen, die die Einrichtung Ihrer privaten Cloud beschreibt, einschließlich Rechenzentren und Knoten>

Zu reproduzierende Schritte:

<Geben Sie nach Möglichkeit Schritte zum Reproduzieren des Problems an>

Diagnosedaten

<Liste der angehängten Dateien>

Beispielfall

Dieser Abschnitt enthält einen Beispielfall für Apigee Edge for Private Cloud.

Problem:

Während wir den Apigee Management Server auf Knoten Nr. 10 im Rahmen von Edge Private Cloud 4.19.06 unter Linux RHEL 7.6 installiert haben, gibt es Fehler.

Fehlermeldung:

<snipped as the output is too long>
Checking for management-server uuid ................................................
Unable to get uuid for management-server.
Error: setup.sh: /opt/apigee/apigee-service/bin/apigee-service exited with unexpected status 1

Problemstartzeit (ISO 8601-Format): Das tritt bei jeder Installation auf.

Problemendzeit (ISO 8601-Format): Nicht zutreffend

Details zur Einrichtung von Edge Private Cloud:

Die Datei network-topology.png wurde angehängt.

Zu reproduzierende Schritte:

Hier ist der Befehl, der zum obigen Fehler geführt hat:

/opt/apigee/apigee-setup/bin/setup.sh -p ms -f /app/NonProdConfig.txt

Diagnosedaten:

Folgende Dateien wurden angehängt:

  • output.txt enthält die vollständige Ausgabe des obigen Befehls einschließlich Fehlermeldung
  • Managementserverprotokolle und
  • Konfigurationsdatei NonProdConfig.txt

Hybrid

Vorlage

Dieser Abschnitt enthält eine Beispielvorlage für Apigee Hybrid.

Problem:

<Geben Sie eine detaillierte Beschreibung des Problems oder des beobachteten Verhaltens an. Geben Sie den Produktnamen und die Version an, falls zutreffend.>

Fehlermeldung:

<Geben Sie die vollständige angezeigte Fehlermeldung an (falls vorhanden)>

Problemstartzeit (ISO 8601-Format):

Problemendzeit (ISO 8601-Format):

Einrichtung von Apigee Hybrid:

  • Apigee Hybrid-Plattform:

    <Informationen für die Plattform bereitstellen, auf der Sie Hybrid und die zugehörige Version installiert haben>

  • Google Cloud-Projekt, hybride Organisation und Umgebung:
    Google Cloud-Projekt-ID:
      <Wenn Sie Google Kubernetes Engine (GKE) verwenden), müssen Sie die Projekt-ID angeben, in der sich die Cluster befinden. Wenn Sie GKE On-Prem, Azure Kubernetes Service oder Amazon EKS verwenden, geben Sie die Projekt-ID an, an die Sie die Logs senden möchten.>
    Apigee hybrid org:
    Apigee hybrid env:
  • Apigee Hybrid und andere CLI-Versionen:
    Apigee Hybrid CLI (apigeectl)-Version:
    Kubectl-Version:
  • Details zum Kubernetes-Clusternamen:
    k8sCluster:
    Name:
    Region:
  • Netzwerktopologie:
    <Fügen Sie die Netzwerktopologie hinzu, die die Einrichtung Ihres Apigee-Hybridnetzwerks einschließlich Rechenzentren, Kubernetes-Clustern, Namespaces und Pods beschreibt.>
  • Überschreibt die YAML-Datei:
    <Anhängen der YAML-Datei anhängen>

Zu reproduzierende Schritte

<Geben Sie nach Möglichkeit Schritte zum Reproduzieren des Problems an>

Diagnosedaten:

<Liste der angehängten Dateien>

Beispielfall

Dieser Abschnitt enthält einen Beispielfall für Apigee Hybrid.

Problem:

Beim Ausführen von Management-APIs in Apigee Hybrid 1.3 werden Fehler ausgegeben.

Fehlermeldung:

[ERROR] 400 Bad Request
{
"error": {
"code": 400,
"message": "Error processing MART request: INTERNAL_ERROR",
"errors": [
{
"message": "Error processing MART request: INTERNAL_ERROR",
"domain": "global",
"reason": "failedPrecondition"
}
],
"status": "FAILED_PRECONDITION"
}
}

Problemstartzeit (ISO 8601-Format): Seit 24.10.2020, 10:30 Uhr PDT

Problemendzeit (ISO 8601-Format): Das Problem wird fortgesetzt.

Einrichtung von Apigee Hybrid:

  • Apigee Hybrid-Plattform
    GKE-Version 1.15.1
  • Google Cloud-Projekt, Hybrid-Organisation und -Umgebung
    Google Cloud-Projekt-ID: apigee-hybrid-123456
      Hinweis: Das ist die ID des Projekts, in dem sich die Cluster befinden
    Apigee hybrid org: apigee-hybrid-123456
    Apigee hybrid env: dev
  • Apigee Hybrid und andere CLI-Versionen:
    Version von Apigee Hybrid CLI (apigeectl):
    Version: 1.2.0
    Commit: ac09109
    Build-ID: 214
    Build-Zeit: 2020-03-30T20:23:36Z
    Go-Version: go1.12

    Kubectl-Version:
    Clientversion:
    version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.0", GitCommit:"e8462b5b5dc2584fdcd18e6bcfe9f1e4d970a529", GitTreeState:"clean", BuildDate:"2019-06-19T16:40:16Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"darwin/amd64"}

        Serverversion:
    version.Info{Major:"1", Minor:"14+", GitVersion:"v1.14.10-gke.36", GitCommit:"34a615f32e9a0c9e97cdb9f749adb392758349a6", GitTreeState:"clean",
  • Details zum Kubernetes-Clusternamen:
    k8sCluster:
    Name: user-cluster-1
    Region: us-east1
  • Netzwerktopologie
    Hängt die Datei network-topology.png an
  • Überschreibt YAML-Datei
    Hängt die Datei overrides.yaml an

Zu reproduzierende Schritte:

Führen Sie die folgende Verwaltungs-API aus, um den Fehler zu beobachten:

curl -X GET --header "Authorization: Bearer <TOKEN>" "https://apigee.googleapis.com/v1/organizations/apigee-hybrid-123456/environments/dev/keyvaluemaps"

Diagnosedaten:

Folgende Dateien wurden angehängt:

  • network-topology.png
  • overrides.yaml file
  • MART-Logs
  • Synchronizer-Logs