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 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
Atualização do OPDK 4.52.01 Mint

Esse problema afeta apenas quem usa o MINT ou o que tem o MINT ativado no Edge para instalações de nuvem privada.

Componente afetado:processador de mensagens de borda

Problema: se a monetização estiver ativada e você estiver instalando a versão 4.52.01 como uma nova instalação ou fazendo upgrade de versões anteriores da nuvem privada, haverá um problema com os processadores de mensagens. Há um aumento gradual na contagem de linhas de execução abertas, o que leva ao esgotamento dos recursos. A seguinte exceção é encontrada no system.log do processador de mensagens de borda:

Error injecting constructor, java.lang.OutOfMemoryError: unable to create new native thread
Vulnerabilidade 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 no 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 da Apigee. Para mais detalhes, consulte o 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 o Cassandra, o 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 nuvem privada:

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

  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ó de 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. Atualize 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ó de 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. Atualize 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á tendo problemas com o 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.

Para verificar o número total de tabelas no Postgres, execute a consulta SQL abaixo:

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 RHEL 8.0

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

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

Política LDAP

149245401: as configurações do pool de conexões LDAP para JNDI definidas pelo 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 sempre 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ão LDAP, siga as etapas abaixo para definir uma alteração global em todas as políticas 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 Java Naming and Directory Interface (JNDI)) 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 há 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 das 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 excedem 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. A presença deles nos registros indica que os URLs do servidor de destino estão sendo removidos do cache do HTTPClient porque o tamanho do cache é muito pequeno.

Solução alternativa: para o Edge para as 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 para todos os processadores de mensagens.

O valor 500 é um exemplo. O valor ideal para sua 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 definir essa propriedade mais alta, e o único efeito seria um tempo de processamento de solicitação 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) com escopo para o nível da organização ou do ambiente causam dados inconsistentes e perda de atualizações.

Observação:essa limitação se aplica apenas ao Edge para nuvem privada. O Edge para nuvem pública e híbrida não tem essa limitação.

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