Stai visualizzando la documentazione relativa a Apigee e Apigee ibrido.
Visualizza
Documentazione di Apigee Edge.
Sintomo
Gli utenti osservano dati incoerenti o nessun dato per entità come prodotti API, app, sviluppatori Mappe valori-chiave (KVM) e cache a intermittenza sull'interfaccia utente ibrida (UI) Apigee e tramite l'API di gestione.
Messaggi di errore
Non è noto che messaggi di errore vengano mostrati in questo scenario.
Cause possibili
Causa | Descrizione |
---|---|
Pod Cassandra non connessi all'anello | I pod Cassandra di tutti i data center non possono essere connessi all'anello Cassandra comune. |
La riparazione del nodetool non è stata eseguita | Il comando nodetool repair potrebbe non essere stato eseguito periodicamente. |
Problemi di connettività di rete | Potrebbero verificarsi problemi di connettività di rete tra i pod Cassandra in data center diversi. |
Passaggi diagnostici comuni
- Recupera le informazioni su una o più entità per cui riscontri questo problema, ad esempio
Prodotti API, App e così via, utilizzando
API Management e
verificare se è possibile vedere risultati diversi quando viene richiamato più volte.
Nella riga di comando, usa i seguenti esempi per inserire
gcloud
credenziali di autenticazione, impostare le variabili di ambiente ed eseguire i comandi API:Scopri i prodotti basati su API:
TOKEN=$(gcloud auth print-access-token) ORG=ORGANIZATION_NAME curl -i -H "Authorization: Bearer $TOKEN" \ "https://apigee.googleapis.com/v1/organizations/$ORG/apiproducts"
Scarica le app:
TOKEN=$(gcloud auth print-access-token) ORG=ORGANIZATION_NAME curl -i -H "Authorization: Bearer $TOKEN" \ "https://apigee.googleapis.com/v1/organizations/$ORG/apps"
Scegli gli sviluppatori:
TOKEN=$(gcloud auth print-access-token) ORG=ORGANIZATION_NAME curl -i -H "Authorization: Bearer $TOKEN" \ "https://apigee.googleapis.com/v1/organizations/$ORG/developers"
Ottieni mappe chiave-valore (KVM):
TOKEN=$(gcloud auth print-access-token) ORG=ORGANIZATION_NAME curl -i -H "Authorization: Bearer $TOKEN" \ "https://apigee.googleapis.com/v1/organizations/$ORG/keyvaluemaps"
Scarica cache:
TOKEN=$(gcloud auth print-access-token) ORG=ORGANIZATION_NAME ENV=ENVIRONMENT_NAME curl -i -H "Authorization: Bearer $TOKEN" \ "https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/caches"
- Se non visualizzi dati o dati diversi quando vengono eseguite le richieste dell'API di gestione di cui sopra, significa che stai riscontrando lo stesso problema osservato nell'interfaccia utente.
Causa: i pod Cassandra non sono connessi ai pod Cassandra di tutti i data center
In un deployment ibrido Apigee in più regioni, se tutti i pod Cassandra non sono connessi allo stesso i dati potrebbero non essere replicati da tutti i pod Cassandra. Di conseguenza, la direzione non riceverà lo stesso set di dati in modo coerente per la stessa query. Esegui le seguenti operazioni passaggi per analizzare questo scenario:
Diagnosi
- Elenca i pod Cassandra:
- Esegui questo comando per controllare lo stato di tutti i pod di Cassandra in ciascun data center.
Nella versione ibrida di Apigee < 1.4.0:
# check cassandra cluster status kubectl -n apigee get pods \ -l app=apigee-cassandra \ --field-selector=status.phase=Running \ -o custom-columns=name:metadata.name --no-headers \ | xargs -I{} sh -c "echo {}; kubectl -n apigee exec {} -- nodetool status"
Nelle versioni ibride di Apigee >= 1.4.0:
# check cassandra cluster status kubectl -n apigee get pods \ -l app=apigee-cassandra \ --field-selector=status.phase=Running \ -o custom-columns=name:metadata.name --no-headers \ | xargs -I{} sh -c "echo {}; kubectl -n apigee exec {} -- nodetool -u jmxuser -pw JMXUSER_PASSWORD status"
- Controlla il risultato del comando precedente e verifica se tutti i pod Cassandra in tutto
i data center sono connessi all'anello Cassandra e in stato Up e Normal (UN).
Output di esempio di un anello Cassandra integro:
kubectl -n apigee get pods \ -l app=apigee-cassandra \ --field-selector=status.phase=Running \ -o custom-columns=name:metadata.name --no-headers \ | xargs -I{} sh -c "echo {}; kubectl -n apigee exec {} -- nodetool -u jmxuser -pw iloveapis123 status" apigee-cassandra-default-0 Datacenter: dc-1 ================ Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 10.0.2.18 1.32 MiB 256 100.0% 2e6051fe-e3ed-4858-aed0-ac9be5270e97 ra-1 UN 10.0.4.10 1.49 MiB 256 100.0% 2396e17f-94fd-4d7d-b55e-35f491a5c1cc ra-1 UN 10.0.3.14 1.38 MiB 256 100.0% 579cf76e-7d6d-46c8-8319-b7cd74ee87c8 ra-1 Datacenter: dc-2 ================ Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 10.8.1.12 1.31 MiB 256 100.0% 3e9f24bf-2c10-4cfd-8217-5be6245c2b9c ra-1 UN 10.8.2.19 1.24 MiB 256 100.0% 1d2e803d-aa31-487b-9503-1e18297efc04 ra-1 UN 10.8.4.4 1.28 MiB 256 100.0% d15ffeef-7929-42c2-a3b1-a3feb85a857b ra-1 apigee-cassandra-default-1 Datacenter: dc-1 ================ Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 10.0.2.18 1.32 MiB 256 100.0% 2e6051fe-e3ed-4858-aed0-ac9be5270e97 ra-1 UN 10.0.4.10 1.49 MiB 256 100.0% 2396e17f-94fd-4d7d-b55e-35f491a5c1cc ra-1 UN 10.0.3.14 1.38 MiB 256 100.0% 579cf76e-7d6d-46c8-8319-b7cd74ee87c8 ra-1 Datacenter: dc-2 ================ Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 10.8.1.12 1.31 MiB 256 100.0% 3e9f24bf-2c10-4cfd-8217-5be6245c2b9c ra-1 UN 10.8.2.19 1.24 MiB 256 100.0% 1d2e803d-aa31-487b-9503-1e18297efc04 ra-1 UN 10.8.4.4 1.28 MiB 256 100.0% d15ffeef-7929-42c2-a3b1-a3feb85a857b ra-1 apigee-cassandra-default-2 Datacenter: dc-1 ================ Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 10.0.2.18 1.32 MiB 256 100.0% 2e6051fe-e3ed-4858-aed0-ac9be5270e97 ra-1 UN 10.0.4.10 1.49 MiB 256 100.0% 2396e17f-94fd-4d7d-b55e-35f491a5c1cc ra-1 UN 10.0.3.14 1.38 MiB 256 100.0% 579cf76e-7d6d-46c8-8319-b7cd74ee87c8 ra-1 Datacenter: dc-2 ================ Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 10.8.1.12 1.31 MiB 256 100.0% 3e9f24bf-2c10-4cfd-8217-5be6245c2b9c ra-1 UN 10.8.2.19 1.24 MiB 256 100.0% 1d2e803d-aa31-487b-9503-1e18297efc04 ra-1 UN 10.8.4.4 1.28 MiB 256 100.0% d15ffeef-7929-42c2-a3b1-a3feb85a857b ra-1
Output di esempio di un anello Cassandra in stato non integro:
kubectl -n apigee get pods \ -l app=apigee-cassandra \ --field-selector=status.phase=Running \ -o custom-columns=name:metadata.name --no-headers \ | xargs -I{} sh -c "echo {}; kubectl -n apigee exec {} -- nodetool -u jmxuser -pw iloveapis123 status" apigee-cassandra-default-0 Datacenter: dc-1 ================ Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 10.0.2.18 1.32 MiB 256 100.0% 2e6051fe-e3ed-4858-aed0-ac9be5270e97 ra-1 DL 10.0.4.10 1.49 MiB 256 100.0% 2396e17f-94fd-4d7d-b55e-35f491a5c1cc ra-1 DL 10.0.3.14 1.38 MiB 256 100.0% 579cf76e-7d6d-46c8-8319-b7cd74ee87c8 ra-1 Datacenter: dc-2 ================ Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 10.8.1.12 1.31 MiB 256 100.0% 3e9f24bf-2c10-4cfd-8217-5be6245c2b9c ra-1 UN 10.8.2.19 1.24 MiB 256 100.0% 1d2e803d-aa31-487b-9503-1e18297efc04 ra-1 DL 10.8.4.4 1.28 MiB 256 100.0% d15ffeef-7929-42c2-a3b1-a3feb85a857b ra-1 apigee-cassandra-default-1 Datacenter: dc-1 ================ Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 10.0.2.18 1.32 MiB 256 100.0% 2e6051fe-e3ed-4858-aed0-ac9be5270e97 ra-1 UN 10.0.4.10 1.49 MiB 256 100.0% 2396e17f-94fd-4d7d-b55e-35f491a5c1cc ra-1 UN 10.0.3.14 1.38 MiB 256 100.0% 579cf76e-7d6d-46c8-8319-b7cd74ee87c8 ra-1 Datacenter: dc-2 ================ Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 10.8.1.12 1.31 MiB 256 100.0% 3e9f24bf-2c10-4cfd-8217-5be6245c2b9c ra-1 UN 10.8.2.19 1.24 MiB 256 100.0% 1d2e803d-aa31-487b-9503-1e18297efc04 ra-1 UN 10.8.4.4 1.28 MiB 256 100.0% d15ffeef-7929-42c2-a3b1-a3feb85a857b ra-1 apigee-cassandra-default-2 Datacenter: dc-1 ================ Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 10.0.2.18 1.32 MiB 256 100.0% 2e6051fe-e3ed-4858-aed0-ac9be5270e97 ra-1 UN 10.0.4.10 1.49 MiB 256 100.0% 2396e17f-94fd-4d7d-b55e-35f491a5c1cc ra-1 UN 10.0.3.14 1.38 MiB 256 100.0% 579cf76e-7d6d-46c8-8319-b7cd74ee87c8 ra-1 Datacenter: dc-2 ================ Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 10.8.1.12 1.31 MiB 256 100.0% 3e9f24bf-2c10-4cfd-8217-5be6245c2b9c ra-1 UN 10.8.2.19 1.24 MiB 256 100.0% 1d2e803d-aa31-487b-9503-1e18297efc04 ra-1 UN 10.8.4.4 1.28 MiB 256 100.0% d15ffeef-7929-42c2-a3b1-a3feb85a857b ra-1
Tieni presente che alcuni pod Cassandra dell'output precedente sono in modalità DL (In attesa e in uscita). . Per ulteriori informazioni, vedi nodetool.
- Se noti pod Cassandra in stato DL (come mostrato nell'output di esempio precedente), questa è la causa del problema.
- Quando viene effettuata una richiesta di recupero delle informazioni su qualsiasi entità tramite o all'API di gestione, se la richiesta raggiunge uno dei pod Cassandra che inattivi, non riceverai alcun dato.
# list cassandra pods kubectl -n apigee get pods -l app=apigee-cassandra
Risoluzione
Esegui i passaggi indicati nella sezione seguente e assicurati che i pod Cassandra nella che presentano problemi sono collegati al data center originale, come descritto in Deployment multiregionale GKE e GKE On-Prem | Apigee.
Causa: la riparazione del nodetool non è stata eseguita
Se il comando nodetool repair
non è stato eseguito periodicamente come attività di manutenzione,
esiste la possibilità di dati incoerenti tra i pod Cassandra. Esegui le seguenti operazioni
passaggi per analizzare questo scenario:
Diagnosi
- Crea un pod di container client Cassandra
apigee-hybrid-cassandra-client
per il debug.
- Elenca tutti i pod Cassandra:
# list cassandra pods kubectl -n=apigee get pods -l app=apigee-cassandra
- Connettiti a uno dei pod Cassandra utilizzando CQLSH:
cqlsh apigee-cassandra-default-0.apigee-cassandra-default.apigee.svc.cluster.local -u ddl_user --ssl
- Elenco
keyspaces
:SELECT * from system_schema.keyspaces;
Output di esempio:
ddl_user@cqlsh> SELECT keyspace_name from system_schema.keyspaces; keyspace_name ----------------------------- system_auth cache_PROJECT_ID_hybrid system_schema kms_PROJECT_ID_hybrid kvm_PROJECT_ID_hybrid rtc_PROJECT_ID_hybrid system_distributed system perses system_traces quota_PROJECT_ID_hybrid (11 rows)
- Identifica
keyspaces
del risultato precedente, elenca ed esegui query su tutte le entità in ogni data center utilizzando CQLSH.Se l'entità incoerente è un prodotto API:
select * from KMS_KEYSPACE.api_product;
Se l'entità incoerente è l'applicazione (
app
):select * from KMS_KEYSPACE.app;
Se l'entità incoerente è
developer
:select * from KMS_KEYSPACE.developer;
Se l'entità incoerente è una mappa chiave-valore:
select * from KVM_KEYSPACE.kvm_map_entry;
Se l'entità incoerente è
cache
:select * from CACHE_KEYSPACE.cache_map_entry;
- Prendi nota del conteggio dei record dall'output di ciascuna delle query precedenti.
- Ripeti i passaggi precedenti per ciascuno dei pod Cassandra in tutti i data center.
- Confronta i conteggi dei record ottenuti da tutti i pod di Cassandra.
- Identifica i pod Cassandra con dati incoerenti.
Risoluzione
- Elenca i pod Cassandra e connettiti a pod Cassandra specifici con dati incoerenti:
# list cassandra pods kubectl -n=apigee get pods -l app=apigee-cassandra # connect to one cassandra pod kubectl -n=apigee exec -it apigee-cassandra-default-0 bash
- Esegui il comando
nodetool repair
su ogni pod Cassandra in ciascun data center:Nella versione ibrida di Apigee < 1.4.0:
nodetool repair
Nelle versioni ibride di Apigee >= 1.4.0:
nodetool -u JMX_USERNAME -pw JMX-PASSWORD repair
- Segui di nuovo la sezione della diagnostica e verifica se i dati sono stati replicati o meno in tutti i pod Cassandra in modo coerente.
- Ripeti i passaggi precedenti per tutti i pod Cassandra con dati incoerenti.
Causa: problemi di connettività di rete
In caso di problemi di connettività di rete tra i data center, i dati di Cassandra potrebbero non ricevere replicata in modo coerente in tutti i pod Cassandra nell'anello di Cassandra. Procedi come descritto di seguito. per analizzare questo scenario:
Diagnosi
- Elenca tutti i pod Cassandra:
# list cassandra pods kubectl -n=apigee get pods -l app=apigee-cassandra
- Esegui questo comando
curl
e telnet sul primo pod Cassandra nella secondo data center (dc-2
) dal primo pod Cassandra nel primo data center (dc-1
) utilizzando la porta7001
:kubectl -n apigee exec -it apigee-cassandra-default-0 bash -- curl -v telnet://DC_2_APIGEE_CASSANDRA_DEFAULT_0_POD_IP:7001
- Se telnet ha esito positivo, viene visualizzato un output simile al seguente:
* Rebuilt URL to: telnet://10.0.4.10:7001/ * Trying 10.0.4.10... * TCP_NODELAY set * Connected to 10.0.4.10 (10.0.4.10) port 7001 (#0)
- In caso contrario, viene visualizzato un errore simile al seguente:
* Rebuilt URL to: telnet://10.0.4.10:7001/ * Trying 10.0.4.10... * TCP_NODELAY set * connect to 10.0.4.10 port 7001 failed: Connection refused * Failed to connect to 10.0.4.10 port 7001: Connection refused * Closing connection 0 curl: (7) Failed to connect to 10.0.4.10 port 7001: Connection refused
Errore di connettività dal pod Cassandra in un data center al pod Cassandra in indica che deve esistere una restrizione del firewall o che problema di connettività di rete.
Risoluzione
- Se questo deployment ibrido Apigee è su GKE, controlla se sono state impostate regole firewall che bloccare il traffico da un data center all'altro e analizzare la connettività di rete risolvere il problema facendo riferimento a Panoramica delle regole firewall VPC.
- Se questo deployment ibrido Apigee è su GKE-on-prem, lavora con il networking pertinente e analizzare il problema di connettività di rete.
Raccogliere dati diagnostici
Se il problema persiste anche dopo aver seguito le istruzioni riportate sopra, raccogli i seguenti dati informazioni di diagnostica e contatta l'assistenza clienti Google Cloud:
- ID del progetto Google Cloud
- L'organizzazione Apigee ibrida
- Il file
overrides.yaml
, mascherando le informazioni sensibili - Stato dei pod Kubernetes in tutti gli spazi dei nomi:
kubectl get pods -A > kubectl-pod-status`date +%Y.%m.%d_%H.%M.%S`.txt
- Un
cluster-info dump
di Kubernetes:# generate kubernetes cluster-info dump kubectl cluster-info dump -A --output-directory=/tmp/kubectl-cluster-info-dump # zip kubernetes cluster-info dump zip -r kubectl-cluster-info-dump`date +%Y.%m.%d_%H.%M.%S`.zip /tmp/kubectl-cluster-info-dump/*
Riferimenti
- Deployment ibrido multiregionale di Apigee su GKE e GKE On-Prem
- Documentazione di Kubernetes
- Comando di stato Cassandra nodetool