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 chiave-valore (KVM) e cache in modo intermittente nell'interfaccia utente (UI) ibrida di Apigee e tramite l'API Management.

Messaggi di errore

In questo scenario non vengono visualizzati messaggi di errore noti.

Cause possibili

Causa Descrizione
Pod di Cassandra non connessi all'anello I pod Cassandra di tutti i data center potrebbero non essere connessi all'anello Cassandra comune.
L'utilità nodetool repair non è stata eseguita Il comando nodetool repair potrebbe non essere stato eseguito periodicamente.
Problemi di connettività di rete Potrebbero esserci problemi di connettività di rete tra i pod Cassandra in data center diversi.

Passaggi comuni per la diagnostica

  1. Recupera le informazioni su una o più entità per le quali riscontri questo problema, ad esempio prodotti API, app e così via, utilizzando l'API Management e verifica se visualizzi risultati diversi quando viene richiamata più volte.

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

    Recupera 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"

    Scarica app:

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

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

    Trovare sviluppatori:

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

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

    Ottenere le 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"

    Get Caches:

    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 visualizzi dati diversi quando vengono eseguite le richieste dell'API Management riportate sopra, significa che stai riscontrando lo stesso problema osservato nell'UI.

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

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

Diagnosi

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

    Su 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 connessi all'anello Cassandra e hanno lo stato Up and 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 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 nello stato DL (Down and Leaving). Per saperne di più, consulta nodetool status.

    • Se noti pod Cassandra con stato DL (come mostrato nell'output dell'esempio precedente), allora questo è il motivo del problema.
    • Quando viene effettuata una richiesta per recuperare le informazioni su qualsiasi entità tramite l'interfaccia utente ibrida o l'API Management, se la richiesta raggiunge uno dei pod Cassandra non funzionanti, non riceverai alcun dato.

Risoluzione

Esegui i passaggi forniti nella sezione seguente e assicurati che i pod Cassandra nel data center problematico siano connessi al data center originale come descritto in Deployment multiregionale 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, esiste la possibilità di dati incoerenti nei pod Cassandra. Per analizzare questo scenario, segui i passaggi riportati di seguito:

Diagnosi

  1. Crea un pod 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 keyspaces dal 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à non coerente è la mappa di coppie chiave-valore:

    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 al pod Cassandra specifico che conteneva 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:

    Su 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 Diagnosi e verifica se i dati sono stati replicati in modo coerente in tutti i pod Cassandra.
  4. Ripeti i passaggi precedenti per tutti i pod Cassandra che contenevano dati incoerenti.

Causa: problemi di connettività di rete

Se si verificano problemi di connettività di rete tra i data center, è possibile che i dati di Cassandra non vengano replicati in modo coerente in tutti i pod Cassandra nell'anello Cassandra. Per analizzare questo scenario, segui questi 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 telnet è riuscito, 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 restrizione del firewall o qualche tipo di problema di connettività di rete.

Risoluzione

  1. Se questo deployment ibrido di Apigee si trova su GKE, verifica se sono impostate regole firewall che bloccano il traffico da un data center all'altro e analizza il problema di connettività di rete consultando la panoramica delle regole firewall VPC.
  2. Se questo deployment ibrido di Apigee si trova su GKE On-Prem, collabora con il team di networking pertinente e analizza il problema di connettività di rete.

Deve raccogliere informazioni diagnostiche

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

  1. L'ID progetto Google Cloud
  2. Organizzazione Apigee hybrid
  3. Il file overrides.yaml, mascherando eventuali 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