4.19.06 Notas de lançamento do Edge para nuvem privada

O Mint não classifica transações inicialmente

O Edge para nuvem privada não avalia as transações inicialmente quando você ativa a monetização de uma organização pela primeira vez. Isso é válido para organizações novas e atuais.

A API de ativação da monetização responde com o ID do job e, após a conclusão, o status do job indica sucesso. No entanto, as chamadas de API monetizadas feitas inicialmente não serão processadas pela monetização e não serão classificadas. Essas transações só vão aparecer nas análises regulares.

Alternativa:

apigee-service edge-message-processor restart

Depois que a monetização é ativada, a reinicialização dos MPs faz com que o Edge carregue a configuração do ZooKeeper na inicialização. Isso acontece a cada reinicialização, o que significa que o problema só se aplica inicialmente.

Vazamento de memória nos servidores de classificação do Mint

Quando uma nova instância do Qpid é registrada em um mxgroup, as filas são criadas sem consumidores, o que resulta no aumento da profundidade da fila até que ela use todos os recursos disponíveis.

Alternativa:

Formato do arquivo de metadados para instalação do apigee-sso

Ao instalar o apigee-sso e usar um arquivo metadata.xml em vez de um URL, se o arquivo metadata.xml não incluir uma nova linha (CRLF) no final, ele não será lido por completo.

Alternativa:

Para contornar esse problema, siga um destes procedimentos:

• Adicione um CRLF ao final do arquivo metadata.xml

  OU

• Usar um local baseado em URL para os metadados

apigee-monit não é compatível com o Amazon Linux 1

Alternativa:

O backup do processador de mensagens não faz backup do conjunto correto de arquivos

Alternativa:

Execute o backup uma segunda vez para fazer backup do conjunto correto de arquivos.

DataAccessException em várias configurações de data center

Em configurações de vários data centers, se um repositório de dados ficar indisponível, você poderá receber o seguinte erro:

DataAccessException: Error while accessing datastore;
Please retry later

O resultado é que o servidor de gerenciamento pode não iniciar porque está tentando se conectar aos nós do Cassandra em dc-1 e dc-2. O DataAccessExceptions ocorre se um nó do Cassandra estiver inativo. Isso também pode resultar em interrupção do tráfego da API, em que os processadores de mensagens informam DataAccessExceptions ao tentar recuperar KVMs.

O estado esperado é que o servidor de gerenciamento não se conecte a componentes do datastore em regiões.

Alternativa

A solução alternativa é cancelar o registro dos seguintes tipos de nós do Cassandra no data center indisponível e depois registrá-los novamente quando os nós do Cassandra estiverem disponíveis:

• kms-datastore
• dc-datastore
• keyvaluemap-datastore

Para cancelar e registrar novamente esses tipos de nós do Cassandra:

1. Use o seguinte comando curl para receber os UUIDs dos nós do Cassandra:

   curl -u ADMIN_EMAIL:ADMIN_PW \
     "http://MS_IP:MS_PORT/v1/servers?region=REGION&pod=GATEWAY_POD \
     &type=CASSANDRA_NODE_TYPE"

   Em que:

   • ADMIN_EMAIL e ADMIN_PW são as credenciais da sua conta da Apigee.
   • MS_IP e MS_PORT são o endereço IP e o número da porta do servidor de gerenciamento.
   • REGION é o nome do data center em que o servidor de gerenciamento está localizado.
   • GATEWAY_POD é o nome do pod, que por padrão é "gateway". No entanto, você pode ter renomeado para outra coisa. Portanto, verifique sua implementação.
   • CASSANDRA_NODE_TYPE é um dos campos kms-datastore, dc-datastore e keyvaluemap-datastore.

   Exemplo:

   curl -u nickdanger@google.com:myP@$$w0rD
     "http://192.168.0.1:8080/v1/servers?region=dc-1&pod=gateway&type=dc-datastore"

   A resposta usa o seguinte formato:

   {
     "internalIP" : "POD_IP_ADDRESS",
     "isUp" : [true|false],
     "pod" : "GATEWAY_POD",
     "reachable" : [true|false],
     "region" : "dc-1",
     "tags" : {
       "property" : [ ]
     },
     "type" : [ "kms-datastore", "dc-datastore", "keyvaluemap-datastore" ],
       "uUID" : "POD_UUID"
   }

   Exemplo:

   {
     "internalIP" : "192.168.1.11",
     "isUp" : false,
     "pod" : "gateway",
     "reachable" : false,
     "region" : "dc-1",
     "tags" : {
       "property" : [ ]
     },
     "type" : "dc-datastore",
     "uUID" : "13cee956-d3a7-4577-8f0f-1694564179e4"
   }

   Anote os valores do campo uUID na resposta. Você vai usar esses comandos para cancelar o registro dos nós.

2. Repita a etapa 1 para cada tipo de nó do Cassandra: kms-datastore, dc-datastore e keyvaluemap-datastore. Anote os UUIDs retornados.
3. Remova o registro dos nós usando o seguinte comando:

   curl -u ADMIN_EMAIL:ADMIN_PW "http://MS_IP:MS_PORT/v1/servers/UUID" -X DELETE

   Em que UUID é o UUID retornado na resposta do comando anterior.

4. Repita a etapa 3 para cada UUID coletado nas etapas 1 e 2.
5. Registre novamente os nós usando o seguinte comando:

   curl -u ADMIN_EMAIL:ADMIN_PW "http://MS_IP:MS_PORT/v1/servers -d \
     "Type=kms-datastore&Type=dc-datastore&Type=keyvaluemap-datastore& \
     Type=counter-datastore&Type=cache-datastore&InternalIP=POD_IP_ADDRESS& \
     region=REGION&pod=GATEWAY_POD" -H \
     'content-type: application/x-www-form-urlencoded' -X POST

Essas operações registram e cancelam o registro de nós do Zookeeper e não têm impacto no cluster do Cassandra. Para mais informações sobre esses comandos, consulte Atualizar registros do datastore.

Política MessageLogging, incluindo informações extras na mensagem de registro

O elemento FormatMessage da política MessageLogging controla o formato da mensagem registrada. Quando FormatMessage=false, a mensagem registrada não deve incluir informações geradas pela Apigee. No entanto, mesmo que você defina FormatMessage=false, a mensagem de registro ainda vai incluir as seguintes informações:

• A pontuação de prioridade
• O carimbo de data/hora

Alternativa: