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 assenti per entità come prodotti API, app, sviluppatori, mappe chiave-valore (KVM) e cache a intermittenza sull'interfaccia utente ibrida di Apigee e tramite l'API di gestione.

Messaggi di errore

Non è noto che vengano visualizzati messaggi di errore in questo scenario.

Cause possibili

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

  1. Recupera le informazioni su una o più entità per cui riscontri il problema, ad esempio prodotti API, app e così via, utilizzando l'API di gestione e verifica se potresti vedere risultati diversi se richiamati più volte.

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

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

    Trova app:

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

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

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

    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 vedi dati o dati diversi quando vengono eseguite le richieste API di gestione riportate sopra, significa che stai riscontrando lo stesso problema osservato nella UI.

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

In un deployment ibrido di Apigee in più regioni, 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à in modo coerente lo stesso set di dati per la stessa query. Per analizzare questo scenario, segui questi passaggi:

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 su ciascun data center.

    Su Apigee versione ibrida < 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"

    Sulle 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"
  3. Controlla il risultato del comando riportato sopra e verifica se tutti i pod Cassandra in tutti i data center sono connessi all'anello Cassandra e nello 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 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 riportato sopra sono in stato DL (Inattiva). Per maggiori informazioni, consulta la pagina relativa allo stato del nodetool.

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

Risoluzione

Esegui i passaggi indicati nella sezione seguente e assicurati che i pod Cassandra nel data center problematico siano connessi al data center originale, come descritto in Deployment per più regioni su 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, è possibile che i dati siano incoerenti tra i pod Cassandra. Per analizzare questo scenario, segui questi passaggi:

Diagnosi

  1. Crea un pod contenitore 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 nel risultato riportato sopra, 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 è la mappa chiave-valore:

    select * from KVM_KEYSPACE.kvm_map_entry;

    Se l'entità incoerente è cache:

    select * from CACHE_KEYSPACE.cache_map_entry;
  6. Annota il conteggio 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 che hanno dati incoerenti.

Risoluzione

  1. Elenca i pod Cassandra e connettiti a uno specifico pod Cassandra che aveva 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 ciascun data center:

    Su Apigee versione ibrida < 1.4.0:

    nodetool repair

    Sulle versioni ibride di Apigee >= 1.4.0:

    nodetool -u JMX_USERNAME -pw JMX-PASSWORD repair
  3. 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.
  4. 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 essere replicati in modo coerente in tutti i pod Cassandra nell'anello di Cassandra. Per analizzare questo scenario, procedi nel seguente modo:

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 sul 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 ha avuto 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)
  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 la presenza di una limitazione del firewall o di un qualche tipo di problema di connettività di rete.

Risoluzione

  1. Se il deployment ibrido di Apigee è su GKE, verifica se sono impostate regole firewall che bloccano il traffico da un data center a un altro e analizza il problema di connettività di rete facendo riferimento alla panoramica delle regole firewall VPC.
  2. Se il 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 dati diagnostici

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

  1. ID progetto Google Cloud
  2. L'organizzazione ibrida Apigee
  3. Il file overrides.yaml, che maschera qualsiasi informazioni sensibili
  4. 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
  5. Un Kubernetes cluster-info dump: 
    # 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