Problemas conhecidos com a Apigee

Você está vendo a documentação do Apigee Edge.
Acesse a documentação da Apigee X.
informações

As seções a seguir descrevem os problemas conhecidos da Apigee. Na maioria dos casos, os problemas listados serão corrigidos em uma versão futura.

Problemas conhecidos com o Apigee Sense

As seções a seguir descrevem os problemas conhecidos do Apigee Sense.

Área Problemas conhecidos
A TorListRule está desativada Devido a um problema contínuo, tivemos que desativar a regra de detecção TorListRule. Quando esse problema for resolvido e a regra for reativada, publicaremos uma nota da versão.

Problemas conhecidos do Edge

Confira nas seções a seguir alguns problemas conhecidos do Edge.

Área Problemas conhecidos
A expiração do cache resulta em um valor cachehit incorreto

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 configuração da política InvalidateCache PurgeChildEntries como verdadeira não funciona corretamente

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.

Problemas conhecidos com a IU do Edge

As seções a seguir descrevem os problemas conhecidos com a IU do Edge.

Área Problemas conhecidos
Não é possível acessar a página de administração da zona de SSO do Edge na barra de navegação após a organização ser mapeada para uma zona de identidade Quando você conectar uma organização a uma zona de identidade, não poderá mais acessar a página de administração da zona SSO do Edge na barra de navegação à esquerda selecionando Administrador > SSO. Como solução alternativa, acesse a página diretamente usando o seguinte URL: https://apigee.com/sso (em inglês)

Problemas conhecidos com o portal integrado

As seções a seguir descrevem os problemas conhecidos do portal integrado.

Área Problemas conhecidos
SmartDocs
  • 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.
Provedor de identidade SAML O logout único (SLO) com o provedor de identidade SAML não é compatível com domínios personalizados. Para ativar um domínio personalizado com um provedor de identidade SAML, deixe o campo URL de saída em branco ao definir as configurações de SAML.
Administrador do portal
  • 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.
Recursos do portal
  • A pesquisa será integrada ao portal integrado em uma versão futura.

Problemas conhecidos com o Edge para nuvem privada

As seções a seguir descrevem os problemas conhecidos do Edge para nuvem privada.

Área Problemas conhecidos
Vulnerabilidade de HTTP/2 da Apigee

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:

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
Atualização do Postgresql ao atualizar para a versão 4.52

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 no ChromeVox 8.0

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.

Política LDAP

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.

Latência alta do processamento de solicitações

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.

Várias entradas para mapas de chave-valor

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.