4.19.06 Notas de lançamento do Edge para nuvem privada

Mint não classifica transações inicialmente

O Edge para nuvem privada não classifica as transações inicialmente quando você ativa a monetização em uma organização pela primeira vez. Isso se aplica a organizações novas e existentes.

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

Alternativa:

apigee-service edge-message-processor restart

Após a ativação da monetização, reiniciar os 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 se aplica apenas inicialmente.

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

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

Alternativa:

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

Ao instalar 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 do arquivo, o arquivo metadata.xml não vai ser lido completamente.

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 o backup do conjunto correto de arquivos

Alternativa:

Execute o backup uma segunda vez e ele deve fazer backup do conjunto correto de arquivos.

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

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

DataAccessException: Error while accessing datastore;
Please retry later

Por isso, talvez o Management Server não seja iniciado porque ele está tentando se conectar ao Cassandra. em dc-1 e dc-2. O DataAccessExceptions ocorre se um nó do Cassandra é para baixo. Isso também pode resultar na interrupção do tráfego da API, quando os processadores de mensagens relatam DataAccessExceptions ao tentar recuperar KVMs.

O estado esperado é que o servidor de gerenciamento não se conecte a componentes do repositório de dados entre regiões.

Alternativa

A solução é cancelar o registro dos seguintes tipos de nó do Cassandra no data center indisponível e registre-os novamente assim que os nós do Cassandra estiverem disponíveis novamente:

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

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

1. Consiga os UUIDs dos nós do Cassandra usando o seguinte comando curl:

   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 Apigee do Compute Engine.
   • MS_IP e MS_PORT são o endereço IP e a porta do servidor de gerenciamento número
   • 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". Você pode ter o renomeou com outro nome, então verifique sua implementação.
   • CASSANDRA_NODE_TYPE é um de 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"
   }

   Observe os valores do campo uUID na resposta. Você vai usá-las para cancelar o registro dos nós.

2. Repita a primeira etapa para cada tipo de nó do Cassandra: kms-datastore. dc-datastore e keyvaluemap-datastore. Não se esqueça de anotar as UUIDs retornados.
3. Cancele 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 que você coletou 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

Observe que essas operações registram e cancelam o registro de nós do Zookeeper e não têm nenhum no aglomerado Cassandra. Para mais informações sobre esses comandos, consulte Atualizar registros do repositório de dados.

Política do 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 precisa 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: