Problemas conhecidos com a Apigee Edge

Quando a variável de fluxo cachehit é usada após a política LookupCache, devido à maneira como os pontos de depuração são enviados para comportamento assíncrono, o LookupPolicy preenche o objeto DebugInfo antes que a chamada de retorno seja executada, resultando em um erro.

Alternativa:repita o processo (faça a segunda chamada) novamente logo após a primeira chamada.

A definição de PurgeChildEntries na política InvalidateCache precisa limpar apenas os valores do elemento KeyFragment, mas limpa todo o cache.

Solução alternativa: use a política KeyValueMapOperations para iterar o controle de versões de cache e ignorar a necessidade de invalidação de cache.

• O Apigee Edge oferece suporte à especificação OpenAPI 3.0 quando você cria especificações usando o editor de especificações e publica APIs usando SmartDocs no portal, embora ainda não haja suporte a um subconjunto de recursos.

  Por exemplo, os recursos a seguir da especificação OpenAPI 3.0 ainda não são compatíveis:

  • Propriedades allOf para combinar e estender esquemas
  • Referências remotas

  Se um recurso incompatível for referenciado na especificação OpenAPI, em alguns casos, as ferramentas ignorarão o recurso, mas ainda assim renderizarão a documentação de referência da API. Em outros casos, um recurso não suportado causará erros que impedem a renderização bem-sucedida da documentação de referência da API. Em ambos os casos, você precisará modificar a especificação OpenAPI para evitar o uso do recurso não compatível até que ele seja compatível em uma versão futura.

  Observação: como o editor de especificações é menos restritivo que o SmartDocs ao renderizar a documentação de referência da API, você pode encontrar resultados diferentes entre as ferramentas.

• Ao usar o Testar esta API no portal, o cabeçalho Accept é definido como application/json, independentemente do valor definido para consumes na especificação OpenAPI.

• No momento, não há suporte para atualizações de portal simultâneas (como edições de página, tema, CSS ou script) de vários usuários.
• Se você excluir uma página de documentação de referência da API do portal, não será possível recriá-la. será necessário excluir e adicionar novamente o produto da API e gerar a documentação de referência da API novamente.
• Ao configurar a Política de Segurança de Conteúdo, as alterações podem levar até 15 minutos para serem totalmente aplicadas.
• Ao personalizar seu tema do portal, pode levar até cinco minutos para que as alterações sejam aplicadas.

• A pesquisa será integrada ao portal integrado em uma versão futura.

Uma vulnerabilidade de negação de serviço (DoS) foi descoberta recentemente em várias implementações do protocolo HTTP/2 (CVE-2023-44487), inclusive na Apigee Edge para nuvem privada. A vulnerabilidade pode levar a um ataque de negação de serviço (DoS) da funcionalidade de gerenciamento da API Apigee. Veja mais detalhes no Boletim de segurança da Apigee GCP-2023-032.

Os componentes do roteador e do servidor de gerenciamento do Edge para nuvem privada estão expostos à Internet e podem ficar vulneráveis. Embora o HTTP/2 esteja ativado na porta de gerenciamento de outros componentes específicos do Edge para nuvem privada, nenhum desses componentes está exposto à Internet. Em componentes que não são do Edge, como Cassandra, Zookeeper e outros, o HTTP/2 não está ativado. Recomendamos que você siga as etapas a seguir para solucionar a vulnerabilidade do Edge para a nuvem privada:

• Etapas do Edge para nuvem privada: versão 4.51.00.11 ou mais recente
• Etapas do Edge para versões de nuvem privada anteriores à 4.51.00.11

Siga estas etapas se você estiver usando a versão 4.51.00.11 ou mais recente da nuvem privada do Edge:

1. Atualize o servidor de gerenciamento:

   1. Em cada nó do servidor de gerenciamento, abra /opt/apigee/customer/application/management-server.properties
   2. Adicione esta linha ao arquivo de propriedades:

      conf_webserver_http2.enabled=false

   3. Reinicie o componente do servidor de gerenciamento:

      apigee-service edge-management-server restart

2. Atualize o processador de mensagens:

   1. Em cada nó do processador de mensagens, abra /opt/apigee/customer/application/message-processor.properties
   2. Adicione esta linha ao arquivo de propriedades:

      conf_webserver_http2.enabled=false

   3. Reinicie o componente do processador de mensagens:

      apigee-service edge-message-processor restart

3. Atualize o roteador:

   1. Em cada nó do roteador, abra /opt/apigee/customer/application/router.properties
   2. Adicione esta linha ao arquivo de propriedades:

      conf_webserver_http2.enabled=false

   3. Reinicie o componente do processador de mensagens:

      apigee-service edge-router restart

4. Atualizar o QPID:

   1. Em cada nó QPID, abra /opt/apigee/customer/application/qpid-server.properties
   2. Adicione esta linha ao arquivo de propriedades:

      conf_webserver_http2.enabled=false

   3. Reinicie o componente do processador de mensagens:

      apigee-service edge-qpid-server restart

5. Atualizar o Postgres:

   1. Em cada nó do Postgres, abra /opt/apigee/customer/application/postgres-server.properties
   2. Adicione esta linha ao arquivo de propriedades:

      conf_webserver_http2.enabled=false

   3. Reinicie o componente do processador de mensagens:

      apigee-service edge-postgres-server restart

Siga estas etapas se você estiver usando o Edge para versões de nuvem privada anteriores à 4.51.00.11:

1. Atualize o servidor de gerenciamento:

   1. Em cada nó do servidor de gerenciamento, abra /opt/apigee/customer/application/management-server.properties
   2. Adicione as duas linhas abaixo ao arquivo de propriedades:

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Reinicie o componente do servidor de gerenciamento:

      apigee-service edge-management-server restart

2. Atualize o processador de mensagens:

   1. Em cada nó do processador de mensagens, abra /opt/apigee/customer/application/message-processor.properties
   2. Adicione as duas linhas abaixo ao arquivo de propriedades:

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Reinicie o componente do processador de mensagens:

      apigee-service edge-message-processor restart

3. Atualize o roteador:

   1. Em cada nó do roteador, abra /opt/apigee/customer/application/router.properties
   2. Adicione as duas linhas abaixo ao arquivo de propriedades:

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Reinicie o componente do processador de mensagens:

      apigee-service edge-router restart

4. Atualizar o QPID:

   1. Em cada nó QPID, abra /opt/apigee/customer/application/qpid-server.properties
   2. Adicione as duas linhas abaixo ao arquivo de propriedades:

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Reinicie o componente do processador de mensagens:

      apigee-service edge-qpid-server restart

5. Atualizar o Postgres:

   1. Em cada nó do Postgres, abra /opt/apigee/customer/application/postgres-server.properties
   2. Adicione as duas linhas abaixo ao arquivo de propriedades:

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Reinicie o componente do processador de mensagens:

      apigee-service edge-postgres-server restart

O Apigee-postgresql está com problemas para fazer upgrade do Edge para nuvem privada versão 4.50 ou 4.51 para a versão 4.52. Os problemas ocorrem principalmente quando o número de tabelas é maior que 500.

Execute a consulta SQL abaixo para verificar o número total de tabelas no Postgres:

select count(*) from information_schema.tables

Solução alternativa: ao atualizar o Apigee Edge 4.50.00 ou 4.51.00 para 4.52.00, realize a etapa preliminar antes de fazer upgrade do Apigee-postgresql.

apigee-mirror não funciona no Red Hat Enterprise Linux (Ela) 8.0.

Solução alternativa: como solução alternativa, instale o apigee-mirror em um servidor que execute uma versão anterior do AOSP ou outro sistema operacional compatível com a Apigee. Em seguida, é possível usar o espelho para adicionar pacotes mesmo que você tenha instalado a Apigee nos servidores do RM 8.0.

149245401: as configurações do pool de conexões LDAP para JNDI definidas por meio do recurso LDAP não são refletidas, e os padrões JNDI causam conexões de uso único todas as vezes. Como resultado, as conexões estão sendo abertas e fechadas toda vez para uso único, criando um grande número de conexões por hora com o servidor LDAP.

Alternativa:

Para alterar as propriedades do pool de conexões LDAP, siga as etapas a seguir para definir uma alteração global em todas as políticas de LDAP.

1. Crie um arquivo de propriedades de configuração se ele ainda não existir:

   /opt/apigee/customer/application/message-processor.properties

2. Adicione o seguinte ao arquivo (substitua os valores das propriedades de nomenclatura e diretório de Java (JNDI, na sigla em inglês) com base no requisito de configuração de recursos 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. Verifique se o arquivo /opt/apigee/customer/application/message-processor.properties é de propriedade de apigee:apigee.
4. Reinicie cada processador de mensagens.

Para verificar se as propriedades JNDI do pool de conexões estão funcionando, execute um tcpdump para observar o comportamento do pool de conexões LDAP ao longo do tempo.

139051927: altas latências de processamento de proxy encontradas no processador de mensagens estão afetando todos os proxies de API. Os sintomas incluem atrasos de 200 a 300 ms nos tempos de processamento em relação aos tempos de resposta normais da API e podem ocorrer de forma aleatória, mesmo com TPS baixo. Isso pode ocorrer quando mais de 50 servidores de destino em que um processador de mensagens faz conexões.

Causa-raiz:os processadores de mensagens mantêm um cache que mapeia o URL do servidor de destino para o objeto HTTPClient em conexões de saída com os servidores de destino. Por padrão, essa configuração é definida como 50, o que pode ser muito baixo para a maioria das implantações. Quando uma implantação tem várias combinações de organização/ambiente em uma configuração e tem um grande número de servidores de destino que ultrapassam 50 no total, os URLs do servidor de destino continuam sendo removidos do cache, causando latências.

Validação: para determinar se a remoção do URL do servidor de destino está causando o problema de latência, procure a palavra-chave "onEvict" ou "Remoção" no system.logs do processador de mensagens. Sua presença nos registros indica que os URLs do servidor de destino estão sendo removidos do cache HTTPClient porque o tamanho do cache é muito pequeno.

Solução alternativa: no Edge para nuvem privada versões 19.01 e 19.06, é possível editar e configurar o cache do HTTPClient, /opt/apigee/customer/application/message-processor.properties:

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

Em seguida, reinicie o processador de mensagens. Faça as mesmas mudanças em todos os processadores de mensagens.

O valor 500 é um exemplo. O valor ideal para a configuração precisa ser maior que o número de servidores de destino aos quais o processador de mensagens se conectaria. Não há efeitos colaterais de aumentar essa propriedade, e o único efeito seria um tempo de processamento de solicitações de proxy do processador de mensagens melhorado.

Observação: o Edge para nuvem privada versão 50.00 tem a configuração padrão de 500.

157933959: inserções e atualizações simultâneas no mesmo mapa de chave-valor (KVM) no escopo do nível da organização ou do ambiente causam dados inconsistentes e perda de atualizações.

Observação:essa limitação só se aplica ao Edge para nuvem privada. O Edge para nuvem pública e híbrido não têm essa limitação.

Para uma solução alternativa no Edge para nuvem privada, crie a KVM no escopo apiproxy.