Problemi noti di Apigee

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 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.

• 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.

• 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.

• La ricerca verrà integrata nel portale integrato in una release futura.

apigee-nginx sui nodi del router di bordo potrebbe segnalare problemi di associazione delle porte o di interruzione del processo nginx.

Componente interessato: router di bordo

Problema: questi problemi potrebbero essere causati da errori di impostazione delle funzionalità durante l'installazione di apigee-nginx.

Soluzione alternativa:puoi impostare manualmente le funzionalità eseguendo il seguente comando:

setcap CAP_NET_BIND_SERVICE=+ep CAP_KILL=+ep /opt/nginx/sbin/nginx

Questo problema riguarda gli utenti che tentano di installare SSO o la nuova UI su RHEL 8 con FIPS abilitato su Edge for Private Cloud 4.53.00.

Componente interessato: SSO e nuova UI

Problema: se stai installando l'SSO o la nuova UI sul sistema operativo RHEL 8 abilitato per FIPS, l'installazione non va a buon fine.

Soluzione: ti invitiamo a utilizzare l'interfaccia utente classica, che è completa di funzionalità e soddisfa le esigenze di funzionalità dell'interfaccia utente.

Questo problema riguarda solo chi utilizza MINT o ha attivato MINT nelle installazioni di Edge per il cloud privato.

Componente interessato:edge-message-processor

Problema: se hai attivato la monetizzazione e stai installando la versione 4.52.01 come installazione nuova o esegui l'upgrade da versioni precedenti di Private Cloud, riscontrerai un problema con gli elaboratori di messaggi. Si verificherà un aumento graduale del numero di thread aperti che porterà all'esaurimento delle risorse. La seguente eccezione viene visualizzata nel file system.log di edge-message-processor:

Error injecting constructor, java.lang.OutOfMemoryError: unable to create new native thread

Di recente è stata scoperta una vulnerabilità di tipo denial of service (DoS) in più implementazioni del protocollo HTTP/2 (CVE-2023-44487), inclusa Apigee Edge per Private Cloud. La vulnerabilità potrebbe causare un attacco DoS della funzionalità di gestione delle API di Apigee. Per ulteriori dettagli, consulta il Bollettino sulla sicurezza di Apigee GCP-2023-032.

I componenti del router e del server di gestione di Edge for Private Cloud sono esposti a internet e possono essere potenzialmente vulnerabili. Sebbene HTTP/2 sia abilitato sulla porta di gestione d'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 i seguenti passaggi per risolvere la vulnerabilità di Edge per il private cloud:

• Passaggi per Edge for Private Cloud versioni 4.51.00.11 o successive
• Passaggi per le versioni di Edge for Private Cloud precedenti alla 4.51.00.11

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

1. Aggiorna il server di gestione:

   1. Su ogni 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 l'elaboratore dei messaggi:

   1. Su ogni nodo del processore di 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 di elaborazione dei messaggi:

      apigee-service edge-message-processor restart

3. Aggiorna il router:

   1. Su ogni nodo del router, apri /opt/apigee/customer/application/router.properties
   2. Aggiungi questa riga al file delle proprietà:

      conf_webserver_http2.enabled=false

   3. Riavvia il componente di elaborazione dei messaggi:

      apigee-service edge-router restart

4. Aggiorna 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 di elaborazione 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 di elaborazione dei messaggi:

      apigee-service edge-postgres-server restart

Segui questi passaggi se utilizzi versioni di Edge for Private Cloud precedenti alla 4.51.00.11:

1. Aggiorna il server di gestione:

   1. Su ogni 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 l'elaboratore dei messaggi:

   1. Su ogni nodo del processore di 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 di elaborazione dei messaggi:

      apigee-service edge-message-processor restart

3. Aggiorna il router:

   1. Su ogni nodo del router, apri /opt/apigee/customer/application/router.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 di elaborazione dei messaggi:

      apigee-service edge-router restart

4. Aggiorna 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 di elaborazione 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 di elaborazione dei messaggi:

      apigee-service edge-postgres-server restart

Apigee-postgresql ha problemi con l'upgrade dalla versione 4.50 o 4.51 di Edge for Private Cloud alla versione 4.52. I problemi si verificano principalmente quando il numero di tabelle è superiore a 500.

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

select count(*) from information_schema.tables

Soluzione alternativa: quando esegui l'aggiornamento di Apigee Edge 4.50.00 o 4.51.00 alla versione 4.52.00, assicurati di eseguire il passaggio preliminare prima di eseguire l'upgrade di Apigee-postgresql.

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

Soluzione alternativa: 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 i pacchetti anche se hai installato Apigee su server RHEL 8.0.

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

Soluzione:

Per modificare le proprietà del pool di connessioni LDAP, segui questi passaggi per impostare una modifica globale in tutti i criteri LDAP.

1. Crea un file di 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 ai requisiti di configurazione della risorsa 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. Riavviare ogni elaboratore 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.

139051927: le alte latenze di elaborazione dei proxy rilevate nel Message Processor influiscono su tutti i proxy API. I sintomi includono ritardi di 200-300 ms nei tempi di elaborazione rispetto ai tempi di risposta dell'API normali e possono verificarsi in modo casuale anche con un TPS basso. Questo può accadere quando sono presenti più di 50 server di destinazione con cui un elaboratore di messaggi effettua connessioni.

Causa principale: gli elaboratori dei messaggi mantengono 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, questo valore è impostato su 50, che potrebbe essere troppo basso per la maggior parte dei deployment. Quando un deployment ha più combinazioni di org/env in una configurazione e un numero elevato di server di destinazione che superano i 50, gli URL dei server di destinazione continuano a essere espulsi dalla cache, causando latenze.

Convalida: per determinare se l'espulsione dell'URL del server di destinazione sta causando il problema di latenza, cerca la parola chiave "onEvict" o "Eviction" nei file system.log di Message Processor. La loro presenza nei log indica che gli URL dei server di destinazione vengono eliminati dalla cache HTTPClient perché le dimensioni della cache sono troppo ridotte.

Soluzione alternativa: per le versioni 19.01 e 19.06 di Edge for Private Cloud, 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 per tutti gli elaboratori di messaggi.

Il valore 500 è un esempio. Il valore ottimale per la configurazione deve essere maggiore del numero di server di destinazione a cui si connette l'elaboratore dei messaggi. L'impostazione di un valore più elevato per questa proprietà non ha effetti collaterali e l'unico impatto sarà un miglioramento dei tempi di elaborazione delle richieste proxy dell'elaborazione dei messaggi.

Nota:la versione 50.00 di Edge for Private Cloud ha l'impostazione predefinita 500.

157933959: gli inserimenti e gli aggiornamenti simultanei della stessa mappa chiave/valore (KVM) limitata all'ambito dell'organizzazione o dell'ambiente causano dati incoerenti e aggiornamenti persi.

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

Per una soluzione alternativa in Edge for Private Cloud, crea la KVM nell'apiproxyambito.