Problemi noti di Apigee Edge

Stai visualizzando la documentazione di Apigee Edge.
Vai alla documentazione di Apigee X.
informazioni

Le seguenti sezioni descrivono i problemi noti di Apigee Edge. Nella maggior parte dei casi, i problemi elencati verranno risolti in una versione futura.

Problemi noti di vari Edge

Le seguenti sezioni descrivono vari problemi noti relativi a Edge.

Area Problemi noti
La scadenza della cache restituisce un valore cachehit errato

Quando la variabile di flusso cachehit viene utilizzata dopo il criterio LookupCache, a causa del modo in cui i punti di debug vengono inviati per il comportamento asincrono, LookupPolicy compila l'oggetto DebugInfo prima dell'esecuzione della richiamata, generando un errore.

Soluzione: ripeti la procedura (effettua una seconda chiamata) di nuovo subito dopo la prima.

L'impostazione del criterio InvalidateCache PurgeChildEntries su true non funziona correttamente

L'impostazione di PurgeChildEntries nel criterio InvalidateCache dovrebbe eliminare definitivamente solo i valori dell'elemento KeyFragment, ma cancellare l'intera cache.

Soluzione:utilizza il criterio KeyValueMapOperations per iterare il controllo delle versioni della cache e ignorare la convalida della cache.

Problemi noti relativi all'interfaccia utente Edge

Le seguenti sezioni descrivono i problemi noti dell'interfaccia utente Edge.

Area Problemi noti
Impossibile accedere alla pagina di amministrazione della zona SSO perimetrale dalla barra di navigazione dopo che l'organizzazione è stata mappata a una zona di identità Quando connetti un'organizzazione a una zona di identità, non puoi più accedere alla pagina di amministrazione delle zone SSO Edge dalla barra di navigazione a sinistra selezionando Amministratore > SSO. Per risolvere il problema, vai alla pagina direttamente utilizzando il seguente URL: https://apigee.com/sso

Problemi noti relativi al portale integrato

Le seguenti sezioni descrivono i problemi noti relativi al portale integrato.

Area Problemi noti
SmartDocs
  • Apigee Edge supporta la specifica OpenAPI 3.0 quando crei le specifiche utilizzando l'editor delle specifiche e pubblichi le API utilizzando SmartDocumenti sul tuo portale, anche se un sottoinsieme di funzionalità non è ancora supportato.

    Ad esempio, le seguenti funzionalità della specifica OpenAPI 3.0 non sono ancora supportate:

    • Proprietà allOf per combinare ed estendere gli schemi
    • Riferimenti remoti

    Se nella specifica OpenAPI viene fatto riferimento a una funzionalità non supportata, in alcuni casi gli strumenti la ignorano, ma visualizzano comunque la documentazione di riferimento dell'API. In altri casi, una funzionalità non supportata causerà errori che impediscono il corretto rendering della documentazione di riferimento dell'API. In entrambi i casi, dovrai modificare la specifica OpenAPI per evitare l'utilizzo della funzionalità non supportata finché non sarà supportata in una release futura.

    Nota: poiché l'editor delle specifiche è meno restrittivo di SmartDocs durante il rendering della documentazione di riferimento dell'API, potresti riscontrare risultati diversi tra gli strumenti.

  • Quando utilizzi Prova questa API nel portale, l'intestazione Accept è impostata su application/json a prescindere dal valore impostato per consumes nella specifica OpenAPI.
Provider di identità SAML L'uscita singola (SLO) con il provider di identità SAML non è supportata per i domini personalizzati. Per attivare un dominio personalizzato con un provider di identità SAML, lascia vuoto il campo Sign-out URL (URL di disconnessione) quando configuri le impostazioni SAML.
Amministratore portale
  • Al momento, gli aggiornamenti simultanei del portale (ad esempio modifiche di pagine, temi, CSS o script) da parte di più utenti non sono supportati.
  • Se elimini dal portale una pagina della documentazione di riferimento dell'API, non potrai ricrearla; dovrai eliminare e aggiungere nuovamente il prodotto API e rigenerare la documentazione di riferimento dell'API.
  • Quando configuri i criteri di sicurezza dei contenuti, l'applicazione completa delle modifiche potrebbe richiedere fino a 15 minuti.
  • Quando personalizzi il tema del portale, l'applicazione completa delle modifiche potrebbe richiedere fino a 5 minuti.
Funzionalità del portale
  • La ricerca verrà integrata nel portale integrato in una release futura.

Problemi noti di Edge per Cloud privato

Le seguenti sezioni descrivono i problemi noti di Edge per il cloud privato.

Area Problemi noti
Vulnerabilità HTTP/2 Apigee

Di recente è stata scoperta una vulnerabilità Denial of Service (DoS) in più implementazioni del protocollo HTTP/2 (CVE-2023-44487), tra cui Apigee Edge per il cloud privato. La vulnerabilità potrebbe portare a un DoS della funzionalità di gestione delle API Apigee. Per ulteriori dettagli, consulta il Bollettino sulla sicurezza Apigee GCP-2023-032.

I componenti del router e del server di gestione Edge per Cloud privato sono esposti a internet e possono essere potenzialmente vulnerabili. Sebbene HTTP/2 sia abilitato sulla porta di gestione di altri componenti specifici di Edge per il cloud privato, nessuno di questi componenti è esposto a internet. Nei componenti non Edge, come Cassandra, Zookeeper e altri, HTTP/2 non è abilitato. Ti consigliamo di seguire questi passaggi per risolvere la vulnerabilità Edge per Cloud privato:

Segui questi passaggi se utilizzi Edge Private Cloud versioni 4.51.00.11 o successive:

  1. Aggiorna il server di gestione:

    1. Su ciascun nodo del server di gestione, apri /opt/apigee/customer/application/management-server.properties
    2. Aggiungi questa riga al file delle proprietà:
      conf_webserver_http2.enabled=false
    3. Riavvia il componente del server di gestione:
      apigee-service edge-management-server restart
  2. Aggiorna il processore dei messaggi:

    1. Su ogni nodo dell'elaboratore dei messaggi, apri /opt/apigee/customer/application/message-processor.properties
    2. Aggiungi questa riga al file delle proprietà:
      conf_webserver_http2.enabled=false
    3. Riavvia il componente dell'elaboratore dei messaggi:
      apigee-service edge-message-processor restart
  3. Aggiorna il router:

    1. Apri /opt/apigee/customer/application/router.properties su ciascun nodo router
    2. Aggiungi questa riga al file delle proprietà:
      conf_webserver_http2.enabled=false
    3. Riavvia il componente dell'elaboratore dei messaggi:
      apigee-service edge-router restart
  4. Aggiorna il QPID:

    1. Su ogni nodo QPID, apri /opt/apigee/customer/application/qpid-server.properties
    2. Aggiungi questa riga al file delle proprietà:
      conf_webserver_http2.enabled=false
    3. Riavvia il componente dell'elaboratore dei messaggi:
      apigee-service edge-qpid-server restart
  5. Aggiorna Postgres:

    1. Su ogni nodo Postgres, apri /opt/apigee/customer/application/postgres-server.properties
    2. Aggiungi questa riga al file delle proprietà:
      conf_webserver_http2.enabled=false
    3. Riavvia il componente dell'elaboratore dei messaggi:
      apigee-service edge-postgres-server restart

Segui questi passaggi se utilizzi Edge per versioni del cloud privato precedenti alla 4.51.00.11:

  1. Aggiorna il server di gestione:

    1. Su ciascun nodo del server di gestione, apri /opt/apigee/customer/application/management-server.properties
    2. Aggiungi le due righe seguenti al file delle proprietà:
      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false
    3. Riavvia il componente del server di gestione:
      apigee-service edge-management-server restart
  2. Aggiorna il processore dei messaggi:

    1. Su ogni nodo dell'elaboratore dei messaggi, apri /opt/apigee/customer/application/message-processor.properties
    2. Aggiungi le due righe seguenti al file delle proprietà:
      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false
    3. Riavvia il componente dell'elaboratore dei messaggi:
      apigee-service edge-message-processor restart
  3. Aggiorna il router:

    1. Apri /opt/apigee/customer/application/router.properties su ciascun nodo router
    2. Aggiungi le due righe seguenti al file delle proprietà:
      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false
    3. Riavvia il componente dell'elaboratore dei messaggi:
      apigee-service edge-router restart
  4. Aggiorna il QPID:

    1. Su ogni nodo QPID, apri /opt/apigee/customer/application/qpid-server.properties
    2. Aggiungi le due righe seguenti al file delle proprietà:
      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false
    3. Riavvia il componente dell'elaboratore dei messaggi:
      apigee-service edge-qpid-server restart
  5. Aggiorna Postgres:

    1. Su ogni nodo Postgres, apri /opt/apigee/customer/application/postgres-server.properties
    2. Aggiungi le due righe seguenti al file delle proprietà:
      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false
    3. Riavvia il componente dell'elaboratore dei messaggi:
      apigee-service edge-postgres-server restart
Upgrade di Postgresql durante l'aggiornamento alla versione 4.52

Apigee-postgresql riscontra problemi con l'upgrade da Edge per Cloud privato versione 4.50 o 4.51 alla versione 4.52. I problemi si verificano principalmente quando il numero di tabelle è maggiore di 500.

Puoi controllare il numero totale di tabelle in Postgres eseguendo la query SQL di seguito:

select count(*) from information_schema.tables

Soluzione:quando aggiorni Apigee Edge 4.50.00 o da 4.51.00 a 4.52.00, assicurati di eseguire il passaggio preliminare prima di eseguire l'upgrade di Apigee-postgresql.

apigee-mirror su RHEL 8.0

apigee-mirror non funziona su Red Hat Enterprise Linux (RHEL) 8.0.

Soluzione: come soluzione alternativa, installa apigee-mirror su un server che esegue una versione precedente di RHEL o un altro sistema operativo supportato per Apigee. Puoi quindi utilizzare il mirror per aggiungere pacchetti anche se hai installato Apigee su server RHEL 8.0.

Criteri LDAP

149245401: le impostazioni del pool di connessioni LDAP per JNDI configurate tramite la risorsa LDAP non vengono applicate e le impostazioni predefinite del formato JNDI causano ogni volta connessioni monouso. Di conseguenza, le connessioni vengono aperte e chiuse ogni volta per utilizzo singolo, creando un elevato numero di connessioni all'ora al server LDAP.

Soluzione:

Per modificare le proprietà del pool di connessioni LDAP, svolgi i passaggi che seguono per impostare una modifica globale per tutti i criteri LDAP.

  1. Crea un file delle proprietà di configurazione se non esiste già:
    /opt/apigee/customer/application/message-processor.properties
  2. Aggiungi quanto segue al file (sostituisci i valori delle proprietà JNDI (Java Naming and Directory Interface) in base al requisito di configurazione delle risorse LDAP).
    bin_setenv_ext_jvm_opts="-Dcom.sun.jndi.ldap.connect.pool.maxsize=20
    -Dcom.sun.jndi.ldap.connect.pool.prefsize=2
    -Dcom.sun.jndi.ldap.connect.pool.initsize=2
    -Dcom.sun.jndi.ldap.connect.pool.timeout=120000
    -Dcom.sun.jndi.ldap.connect.pool.protocol=ssl"
  3. Assicurati che il file /opt/apigee/customer/application/message-processor.properties sia di proprietà di apigee:apigee.
  4. Riavvia ciascun processore di messaggi.

Per verificare che le proprietà JNDI del pool di connessioni vengano applicate, puoi eseguire un tcpdump per osservare il comportamento del pool di connessioni LDAP nel tempo.

Latenza elevata di elaborazione delle richieste

139051927: Le latenze elevate di elaborazione proxy rilevate nel processore di messaggi interessano tutti i proxy API. I sintomi includono un ritardo di 200-300 ms nei tempi di elaborazione rispetto ai normali tempi di risposta dell'API e possono verificarsi in modo casuale anche con TPS bassi. Questo può verificarsi quando più di 50 server di destinazione in cui un processore dei messaggi effettua connessioni.

Causa principale: i processori dei messaggi conservano una cache che mappa l'URL del server di destinazione all'oggetto HTTPClient per le connessioni in uscita ai server di destinazione. Per impostazione predefinita, questa impostazione è impostata su 50, che potrebbe essere troppo bassa per la maggior parte dei deployment. Quando un deployment ha più combinazioni organizzazione/ambiente in una configurazione e ha un numero elevato di server di destinazione che superano i 50 in totale, gli URL dei server di destinazione continuano a essere rimossi dalla cache, causando latenze.

Convalida: per determinare se l'eliminazione dell'URL del server di destinazione causa il problema di latenza, cerca la parola chiave "onEvict" o "Eviction" nel sistema di elaborazione dei messaggi system.logs. La presenza nei log indica che gli URL dei server di destinazione vengono rimossi dalla cache HTTPClient perché le dimensioni della cache sono troppo ridotte.

Soluzione:per Edge per Cloud privato versioni 19.01 e 19.06, puoi modificare e configurare la cache HTTPClient, /opt/apigee/customer/application/message-processor.properties:

conf/http.properties+HTTPClient.dynamic.cache.elements.size=500

Quindi, riavvia il processore di messaggi. Apporta le stesse modifiche a tutti gli elaboratori dei messaggi.

Il valore 500 è un esempio. Il valore ottimale per la configurazione dovrebbe essere maggiore del numero di server di destinazione a cui il processore dei messaggi si connetterà. L'impostazione di questa proprietà a un livello superiore non ha effetti collaterali e l'unico effetto è un miglioramento dei tempi di elaborazione delle richieste proxy dell'elaboratore dei messaggi.

Nota:l'impostazione predefinita di Edge per Cloud privato 50.00 è 500.

Più voci per le mappe chiave-valore

157933959: l'inserimento e gli aggiornamenti simultanei della stessa mappa chiave-valore (KVM) con ambito a livello di organizzazione o ambiente causa dati incoerenti e aggiornamenti persi.

Nota:questo limite si applica solo a Edge per il cloud privato. Edge per il cloud pubblico e il cloud ibrido non presentano questa limitazione.

Per una soluzione alternativa in Edge per il cloud privato, crea il KVM nell'ambito apiproxy.