Dati incoerenti/inesistenti per le entità nella UI ibrida o tramite le API di gestione

Stai visualizzando la documentazione di Apigee e Apigee hybrid.
Visualizza la documentazione di Apigee Edge.

Sintomo

Gli utenti osservano dati incoerenti o nessun dato per entità come prodotti API, app, sviluppatori, mappe di valori chiave (KVM) e cache in modo intermittente nell'interfaccia utente (UI) ibrida di Apigee e tramite l'API di gestione.

Messaggi di errore

Non sono noti messaggi di errore in questo scenario.

Cause possibili

Causa Descrizione
Pod di Cassandra non connessi all'anello I pod Cassandra di tutti i data center potrebbero non essere collegati all'anello Cassandra comune.
La riparazione di 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 di diagnostica comuni

  1. Recupera le informazioni su una o più entità per le quali si verifica il problema, ad esempio API, app e così via, utilizzando l'API Management e verifica se puoi vedere risultati diversi quando viene invocata più volte.

    Nella riga di comando, utilizza i seguenti esempi per recuperare le credenziali di autenticazione gcloud, impostare le variabili di ambiente ed eseguire i comandi API:

    Ottieni i prodotti API:

    TOKEN=$(gcloud auth print-access-token)
ORG=ORGANIZATION_NAME

curl -i -H "Authorization: Bearer $TOKEN" \
"https://apigee.googleapis.com/v1/organizations/$ORG/apiproducts"

    Ottieni app:

    TOKEN=$(gcloud auth print-access-token)
ORG=ORGANIZATION_NAME

curl -i -H "Authorization: Bearer $TOKEN" \
"https://apigee.googleapis.com/v1/organizations/$ORG/apps"

    Ottieni 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 di valori chiave (KVM):

    TOKEN=$(gcloud auth print-access-token)
ORG=ORGANIZATION_NAME

curl -i -H "Authorization: Bearer $TOKEN" \
"https://apigee.googleapis.com/v1/organizations/$ORG/keyvaluemaps"

    Ottieni 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"
  2. Se non visualizzi dati o dati diversi quando vengono eseguite le richieste dell'API di gestione riportate sopra, significa che stai riscontrando lo stesso problema osservato nell'interfaccia utente.

Causa: i pod Cassandra non sono collegati ai pod Cassandra di tutti i data center

In un deployment ibrido Apigee multiregione, se tutti i pod Cassandra non sono collegati allo stesso anello Cassandra, i dati potrebbero non essere replicati da tutti i pod Cassandra. Di conseguenza, il piano di gestione non riceverà in modo coerente lo stesso set di dati per la stessa query. Per analizzare questo scenario, svolgi i seguenti passaggi:

Diagnosi

  1. Elenca i pod Cassandra:
    2. # list cassandra pods
kubectl -n apigee get pods -l app=apigee-cassandra
  2. Esegui il seguente comando per controllare lo stato di tutti i pod Cassandra in ogni data center.

    In Apigee hybrid versione < 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 di Apigee hybrid >= 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"
  3. Controlla il risultato del comando precedente e verifica se tutti i pod Cassandra in tutti i data center sono collegati all'anello Cassandra e sono in stato Up and Normal (UN).

    Output di esempio di un anello Cassandra funzionante:

    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 non in stato di salute:

    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 dei pod Cassandra dell'output riportato sopra sono in stato DL (Down and Leaving). Per ulteriori informazioni, consulta stato di nodetool.

    • Se noti pod Cassandra in stato DL (come mostrato nell'output dell'esempio precedente), questa è la causa del problema.
    • Quando viene effettuata una richiesta per recuperare le informazioni su qualsiasi entità tramite la UI ibrida o l'API di gestione, se la richiesta colpisce uno dei pod Cassandra inattivi, non riceverai alcun dato.

Risoluzione

Esegui i passaggi descritti nella sezione seguente e assicurati che i pod Cassandra nel data center problematico siano collegati al data center originale come descritto in Deployment in più regioni su GKE e GKE on-prem | Apigee.

Causa: la riparazione di nodetool non è stata eseguita

Se il comando nodetool repair non è stato eseguito periodicamente come attività di manutenzione, è possibile che i dati non siano coerenti nei pod Cassandra. Per analizzare questo scenario, svolgi i seguenti passaggi:

Diagnosi

  1. Crea un pod di container client Cassandra apigee-hybrid-cassandra-client per il debug.
  2. Elenca tutti i pod Cassandra: 
    # list cassandra pods
kubectl -n=apigee get pods -l app=apigee-cassandra
  3. Connettiti a uno dei pod Cassandra utilizzando CQLSH: 
    cqlsh apigee-cassandra-default-0.apigee-cassandra-default.apigee.svc.cluster.local -u ddl_user --ssl
  4. 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)
  5. Identifica il keyspaces dal risultato precedente, elenca e esegui query su tutte le entità in ogni data center utilizzando CQLSH.

    Se l'entità incoerente è il prodotto API:

    select * from KMS_KEYSPACE.api_product;

    Se l'entità non coerente è application (app):

    select * from KMS_KEYSPACE.app;

    Se l'entità incoerente è developer:

    select * from KMS_KEYSPACE.developer;

    Se l'entità non coerente è una mappa di valori chiave:

    select * from KVM_KEYSPACE.kvm_map_entry;

    Se l'entità incoerente è cache:

    select * from CACHE_KEYSPACE.cache_map_entry;
  6. Prendi nota dei conteggi dei record dall'output di ciascuna delle query precedenti.
  7. Ripeti i passaggi precedenti per ciascuno dei pod Cassandra in tutti i data center.
  8. Confronta i conteggi dei record ottenuti da tutti i pod Cassandra.
  9. Identifica i pod Cassandra con dati incoerenti.

Risoluzione

  1. Elenca i pod Cassandra e connettiti a un pod Cassandra specifico 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
  2. Esegui il comando nodetool repair su ogni pod Cassandra in ogni data center:

    In Apigee hybrid versione < 1.4.0:

    nodetool repair

    Nelle versioni di Apigee hybrid >= 1.4.0:

    nodetool -u JMX_USERNAME -pw JMX-PASSWORD repair
  3. Segui di nuovo la sezione di diagnostica e verifica se i dati sono stati replicati in modo coerente su tutti i pod Cassandra.
  4. Ripeti i passaggi precedenti per tutti i pod Cassandra con dati incoerenti.

Causa: problemi di connettività di rete

Se si verificano problemi di connettività di rete tra i data center, i dati di Cassandra potrebbero non essere replicati in modo coerente in tutti i pod Cassandra nell'anello Cassandra. Per analizzare questo scenario, svolgi i seguenti passaggi:

Diagnosi

  1. Elenca tutti i pod Cassandra: 
    # list cassandra pods
kubectl -n=apigee get pods -l app=apigee-cassandra
  2. Esegui il seguente comando curl e telnet al primo pod Cassandra nel secondo data center (dc-2) dal primo pod Cassandra nel primo data center (dc-1) utilizzando la porta 7001: 
      kubectl -n apigee exec -it apigee-cassandra-default-0 bash -- curl -v telnet://DC_2_APIGEE_CASSANDRA_DEFAULT_0_POD_IP:7001
  3. Se la connessione telnet è andata a buon fine, 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)
  4. 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

    L'errore di connettività dal pod Cassandra in un data center al pod Cassandra in un altro data center indica che deve esserci una limitazione del firewall o qualche tipo di problema di connettività di rete.

Risoluzione

  1. Se questo deployment ibrida di Apigee è su GKE, controlla se sono impostate regole firewall che bloccano il traffico da un data center all'altro e analizza il problema di connettività di rete facendo riferimento alla panoramica delle regole firewall VPC.
  2. Se questo deployment ibrido di Apigee è su GKE on-prem, collabora con il team di networking pertinente e analizza il problema di connettività di rete.

Deve raccogliere informazioni di diagnostica

Se il problema persiste anche dopo aver seguito le istruzioni riportate sopra, raccogli le seguenti informazioni di diagnostica e poi contatta l'assistenza clienti Google Cloud:

  1. L'ID progetto Google Cloud
  2. L'organizzazione Apigee hybrid
  3. Il file overrides.yaml, che maschera le informazioni sensibili
  4. Stato del pod Kubernetes in tutti gli spazi dei nomi: 
    kubectl get pods -A > kubectl-pod-status`date +%Y.%m.%d_%H.%M.%S`.txt
  5. Un cluster-info dump 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