4.19.06 Notas de la versión de Edge para nube privada

Mint no califica las transacciones inicialmente

Edge para la Nube privada no califica las transacciones inicialmente cuando habilitas la monetización por primera vez para una organización. Esto se aplica a las organizaciones nuevas y existentes.

La API de habilitación de la monetización responde con el ID del trabajo y, cuando se completa, el estado del trabajo indicará que se realizó correctamente. Sin embargo, las llamadas a la API monetizadas que se realicen inicialmente no se procesarán para la monetización ni se calificarán. Estas transacciones solo se mostrarán en las estadísticas normales.

Solución alternativa:

apigee-service edge-message-processor restart

Después de habilitar la monetización, reiniciar los MP hace que Edge cargue la configuración de ZooKeeper al inicio. Esto sucede cada vez que se reinicia el dispositivo, lo que significa que el problema solo se aplica inicialmente.

Fuga de memoria en los servidores de calificación de Mint

Cuando se registra una nueva instancia de Qpid en un mxgroup, las colas se compilan sin consumidores, lo que hace que la profundidad de la cola aumente hasta que se utilizan todos los recursos disponibles.

Solución alternativa:

Formato de archivo de metadatos para la instalación de apigee-sso

Cuando se instala apigee-sso y se usa un archivo metadata.xml en lugar de una URL, si el archivo metadata.xml no incluye una línea nueva (CRLF) al final del archivo, el archivo metadata.xml no se lee por completo.

Solución alternativa:

Para solucionar este problema, puedes realizar una de las siguientes acciones:

• Agrega un CRLF al final del archivo metadata.xml

  O

• Usa una ubicación basada en URL para los metadatos

apigee-monit no es compatible con Amazon Linux 1

Solución alternativa:

La copia de seguridad del Message Processor no crea una copia de seguridad del conjunto correcto de archivos

Solución alternativa:

Ejecuta la copia de seguridad por segunda vez y debería crear una copia de seguridad del conjunto correcto de archivos.

DataAccessException en configuraciones de varios centros de datos

En las configuraciones de varios centros de datos, si un almacén de datos deja de estar disponible, es posible que veas el siguiente error:

DataAccessException: Error while accessing datastore;
Please retry later

El resultado es que es posible que el servidor de administración no se inicie porque intenta conectarse a los nodos de Cassandra en dc-1 y dc-2. El error DataAccessExceptions se produce si un nodo de Cassandra está inactivo. Esto también podría provocar interrupciones en el tráfico de la API, en las que los procesadores de mensajes informen DataAccessExceptions cuando intenten recuperar KVM.

Ten en cuenta que el estado esperado es que el servidor de administración no se conecte a los componentes del almacén de datos en todas las regiones.

Solución alternativa

La solución alternativa consiste en anular el registro de los siguientes tipos de nodos de Cassandra en el centro de datos no disponible y, luego, volver a registrarlos después de que los nodos de Cassandra estén disponibles nuevamente:

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

Para anular y volver a registrar estos tipos de nodos de Cassandra, haz lo siguiente:

1. Obtén los UUID de los nodos de Cassandra con el siguiente comando curl:

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

   Donde:

   • ADMIN_EMAIL y ADMIN_PW son las credenciales de tu cuenta de Apigee.
   • MS_IP y MS_PORT son la dirección IP y el número de puerto del servidor de administración.
   • REGION es el nombre del centro de datos en el que se encuentra el servidor de administración.
   • GATEWAY_POD es el nombre del pod, que, de forma predeterminada, es "gateway". Sin embargo, es posible que le hayas cambiado el nombre, así que verifica tu implementación.
   • CASSANDRA_NODE_TYPE es uno de kms-datastore, dc-datastore y keyvaluemap-datastore.

   Por ejemplo:

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

   La respuesta usa el siguiente 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 ejemplo:

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

   Anota los valores del campo uUID en la respuesta. Los usarás para anular el registro de los nodos.

2. Repite el paso uno para cada tipo de nodo de Cassandra: kms-datastore, dc-datastore y keyvaluemap-datastore. Asegúrate de tomar nota de los UUID que se devuelven.
3. Anula el registro de los nodos con el siguiente comando:

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

   Aquí, UUID es el UUID que se devolvió en la respuesta del comando anterior.

4. Repite el paso 3 para cada UUID que recopilaste en los pasos 1 y 2.
5. Vuelve a registrar los nodos con el siguiente 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

Ten en cuenta que estas operaciones registran y anulan el registro de nodos de Zookeeper, y no tienen ningún impacto en el clúster de Cassandra. Para obtener más información sobre estos comandos, consulta Actualiza los registros del almacén de datos.

Política MessageLogging que incluye información adicional en el mensaje de registro

El elemento FormatMessage de la política MessageLogging controla el formato del mensaje registrado. Cuando es FormatMessage=false, se supone que el mensaje registrado no debe incluir ninguna información generada por Apigee. Sin embargo, incluso si configuras FormatMessage=false, el mensaje de registro aún incluye la siguiente información:

• La puntuación de prioridad
• La marca de tiempo

Solución alternativa: