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

La acuñación no califica las transacciones en un principio

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

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

Solución alternativa:

apigee-service edge-message-processor restart

Después de habilitar la monetización, reiniciar los MPs provoca que Edge cargue la configuración de ZooKeeper al inicio. Esto sucede con cada reinicio, lo que significa que el problema solo se aplica al principio.

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

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

Solución alternativa:

Formato de archivo de metadatos para la instalación de Apigee-SO

Cuando instalas apigee-sso y usas 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

• Usar 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 procesador de mensajes no crea una copia de seguridad del conjunto correcto de archivos

Solución alternativa:

Ejecuta la copia de seguridad por segunda vez. Debería crearse el conjunto de archivos correcto.

DataAccessException en varias configuraciones de centros de datos

En varias configuraciones de 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 está intentando conectarse a Cassandra. en dc-1 y dc-2. El DataAccessExceptions se produce si un nodo de Cassandra está fuera de servicio. Esto también podría provocar la interrupción del tráfico de la API, en la que Message Processors informa DataAccessExceptions mientras se intenta recuperar los 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. entre regiones.

Solución alternativa

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

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

Para anular el registro de estos tipos de nodos de Cassandra y volver a registrarlos, haz lo siguiente:

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

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

   Aquí:

   • ADMIN_EMAIL y ADMIN_PW son las credenciales de tu de servicio predeterminada.
   • MS_IP y MS_PORT son la dirección IP y el puerto del servidor de administración de la fila.
   • REGION es el nombre del centro de datos en el que se encuentra el servidor de administración. ubicado.
   • GATEWAY_POD es el nombre del Pod, que es “puerta de enlace” de forma predeterminada. Es posible que tengas le cambiaste el nombre a otro 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 UUID que se muestran
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

   Donde UUID es el UUID que se muestra 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 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 de MessageLogging que incluye información adicional en el mensaje de registro

El elemento FormatMessage de la política de 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 incluirá la siguiente información:

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

Solución alternativa: