4.19.06 Notas de lançamento do Edge para nuvem privada

Mint não avaliam as transações inicialmente

O Edge para a nuvem privada não classifica 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 existentes.

A API de ativação de monetização responde com o ID da tarefa e, após a conclusão, o status da tarefa indicará que ela foi bem-sucedida. No entanto, as chamadas de API monetizadas feitas inicialmente não serão processadas pela monetização nem classificadas. Essas transações só vão aparecer em análises regulares.

Alternativa:

apigee-service edge-message-processor restart

Depois que a monetização for ativada, 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 de servidores com classificação de entalhe

Quando uma nova instância do Qpid é registrada em um mxgroup, as filas são criadas sem consumidores, o que aumenta a profundidade da fila até que todos os recursos disponíveis sejam usados.

Alternativa:

Formato do arquivo de metadados para apigee-sso install

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

Alternativa:

Para contornar esse problema, siga um destes procedimentos:

• Adicione um CRLF ao final do arquivo metadata.xml

  OU

• Usar um local com base 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 está fazendo backup do conjunto correto de arquivos

Alternativa:

Faça o backup uma segunda vez para ter o conjunto de arquivos correto.

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

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

Observe que o estado esperado é que o servidor de gerenciamento não se conecte a componentes do armazenamento de dados entre regiões.

Alternativa

A solução alternativa é cancelar o registro dos seguintes tipos de nó do Cassandra no data center indisponível e registrá-los novamente quando eles 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 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". Talvez você tenha renomeado como outra coisa, então verifique sua implementação.
   • CASSANDRA_NODE_TYPE é uma destas opções: kms-datastore, dc-datastore ou keyvaluemap-datastore.

   Por 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"
   }

   Por 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ê as usará 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. Anote os 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

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

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 se você definir FormatMessage=false, a mensagem de registro ainda incluirá as seguintes informações:

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

Alternativa: