Estás viendo la documentación de Apigee Edge.
Ve a la
documentación de Apigee X. Información
En las siguientes secciones, se describen los problemas conocidos de Apigee. En la mayoría de los casos, los problemas mencionados se solucionarán en una versión futura.
Problemas conocidos con Apigee Sense
En las siguientes secciones, se describen los problemas conocidos de Apigee Sense.
Área | Errores conocidos |
---|---|
Se inhabilitó TorListRule |
Debido a un problema actual, tuvimos que inhabilitar la regla de detección TorListRule . Cuando se resuelva el problema y se vuelva a habilitar la regla, publicaremos una nota de la versión.
|
Otros problemas conocidos de Edge
En las siguientes secciones, se describen varios problemas conocidos con Edge.
Área | Errores conocidos |
---|---|
El vencimiento de la caché genera un valor de cachehit incorrecto |
Cuando la variable de flujo Solución alternativa: Repite el proceso (haz una segunda llamada) justo después de la primera llamada. |
No funciona correctamente la configuración de la política InvalidateCache PurgeChildEntries como verdadera. |
Si configuras Solución alternativa: Usa la política de KeyValueMapOperations para iterar el control de versiones de la caché y evitar la necesidad de invalidar la caché. |
Problemas conocidos con la IU de Edge
En las siguientes secciones, se describen los problemas conocidos de la IU de Edge.
Área | Errores conocidos |
---|---|
No puede acceder a la página Administración de zonas de SSO de Edge desde la barra de navegación después de que la organización se asigna a una zona de identidad | Cuando conectas una organización a una zona de identidad, ya no puedes acceder a la página Administración de zonas de SSO de Edge desde la barra de navegación izquierda cuando seleccionas Administrador > SSO. Como solución alternativa, navega a la página directamente con la siguiente URL: https://apigee.com/sso. |
Problemas conocidos con el portal integrado
En las siguientes secciones, se describen los problemas conocidos con el portal integrado.
Área | Errores conocidos |
---|---|
SmartDocs |
|
Proveedor de identidad de SAML | El cierre de sesión único (SLO) con el proveedor de identidad SAML no es compatible con los dominios personalizados. Para habilitar un dominio personalizado con un proveedor de identidad de SAML, deja el campo URL de cierre de sesión en blanco cuando establezcas la configuración de SAML. |
Administrador del portal |
|
Funciones del portal |
|
Problemas conocidos con Edge para la nube privada
En las siguientes secciones, se describen los problemas conocidos de Edge para la nube privada.
Área | Errores conocidos |
---|---|
Vulnerabilidad HTTP/2 de Apigee | Hace poco, se descubrió una vulnerabilidad de denegación del servicio (DoS) en varias implementaciones del protocolo HTTP/2 (CVE-2023-44487), incluida Apigee Edge para nube privada. La vulnerabilidad podría causar un DoS en la funcionalidad de administración de APIs de Apigee. Para obtener más detalles, consulta el Boletín de seguridad de Apigee GCP-2023-032. Los componentes del router y del servidor de administración de Edge para la nube privada están expuestos a Internet y pueden ser vulnerables. Aunque HTTP/2 está habilitado en el puerto de administración de otros componentes específicos de Edge de Edge para la nube privada, ninguno de esos componentes está expuesto a Internet. En los componentes que no son de Edge, como Cassandra, Zookeeper y otros, HTTP/2 no está habilitado. Te recomendamos que sigas estos pasos para abordar la vulnerabilidad de Edge de la nube privada:
Sigue estos pasos si usas las versiones 4.51.00.11 o posteriores de Edge Private Cloud:
Sigue estos pasos si usas Edge para versiones de nube privada anteriores a 4.51.00.11:
|
Actualización de Postgresql cuando se actualiza a la versión 4.52 | Apigee-postgresql tiene problemas con la actualización de Edge para la nube privada 4.50 o 4.51 a la versión 4.52. Los problemas ocurren principalmente cuando la cantidad de tablas es mayor que 500. Puedes verificar la cantidad total de tablas en Postgres ejecutando la siguiente consulta en SQL: select count(*) from information_schema.tables Solución alternativa: Cuando actualices Apigee Edge 4.50.00 o 4.51.00 a 4.52.00, asegúrate de realizar el paso preliminar antes de actualizar Apigee-postgresql. |
apigee-mirror en RHEL 8.0 |
Solución alternativa: Como solución alternativa, instala |
Política de LDAP | 149245401: la configuración del grupo de conexiones LDAP para JNDI establecida a través del recurso LDAP no se refleja y los valores predeterminados de JNDI causan conexiones de un solo uso cada vez. Como resultado, las conexiones se abren y se cierran cada vez para un solo uso, lo que crea una gran cantidad de conexiones por hora al servidor LDAP. Solución alternativa: Para cambiar las propiedades del grupo de conexiones LDAP, sigue los siguientes pasos a fin de establecer un cambio global en todas las políticas de LDAP.
Para verificar que las propiedades de JNDI de tu grupo de conexiones tengan efecto, puedes realizar un tcpdump a fin de observar el comportamiento del grupo de conexiones LDAP a lo largo del tiempo. |
Alta latencia de procesamiento de solicitudes | 139051927: Las latencias altas de procesamiento de proxy que se encontraron en el procesador de mensajes afectan a todos los proxies de API. Los síntomas incluyen retrasos de 200 a 300 ms en los tiempos de procesamiento durante los tiempos de respuesta normales de la API y pueden ocurrir de forma aleatoria, incluso con un TPS bajo. Esto puede ocurrir cuando hay más de 50 servidores de destino en los que un procesador de mensajes realiza conexiones. Causa raíz: Los procesadores de mensajes mantienen una caché que asigna la URL del servidor de destino al objeto HTTPClient para las conexiones salientes a los servidores de destino. Según la configuración predeterminada, este parámetro de configuración se establece en 50, que puede ser demasiado bajo para la mayoría de las implementaciones. Cuando una implementación tiene varias combinaciones de organización y entorno en una configuración, y tiene una gran cantidad de servidores de destino que superan los 50 en total, las URLs del servidor de destino se siguen expulsando de la caché, lo que causa latencias. Validación: Para determinar si el expulsión de la URL del servidor de destino es la causa del problema de latencia, busca la palabra clave “onEvict” o “Expulsión” en el procesador de mensajes de system.logs. Su presencia en los registros indica que las URL del servidor de destino se están expulsando de la caché HTTPClient porque el tamaño de la caché es demasiado pequeño. Solución alternativa: Para las versiones 19.01 y 19.06 de Edge para la nube privada, puedes editar y configurar la caché del cliente HTTP, conf/http.properties+HTTPClient.dynamic.cache.elements.size=500 Luego, reinicia el procesador de mensajes. Realiza los mismos cambios para todos los procesadores de mensajes. El valor 500 es un ejemplo. El valor óptimo para tu configuración debe ser superior a la cantidad de servidores de destino a los que se conectaría el procesador de mensajes. No hay efectos secundarios si se configura una propiedad más alta, y el único efecto sería mejorar los tiempos de procesamiento de las solicitudes de proxy del procesador de mensajes.
Nota: Edge para nube privada versión 50.00 tiene la configuración predeterminada de 500. |
Varias entradas para mapas de pares clave-valor | 157933959: Las inserciones y actualizaciones simultáneas en el mismo mapa de clave-valor (KVM) con alcance a nivel de la organización o del entorno provocan datos incoherentes y pérdidas de actualizaciones. Nota: Esta limitación solo se aplica a Edge para la nube privada. Los perímetros para la nube híbrida y la nube pública no tienen esta limitación. A fin de obtener una solución alternativa en Edge para la nube privada, crea el KVM en el
permiso |