Znane problemy z Apigee

Gdy po zasadzie LookupCache jest używana zmienna przepływu cachehit, ze względu na sposób wysyłania punktów debugowania w celu asynchronicznego działania LookupPolicy wypełnia obiekt DebugInfo przed wykonaniem wywołania zwrotnego, co skutkuje błędem.

Obejście: powtórz ten proces (utwórz drugie wywołanie) tuż po pierwszym wywołaniu.

Ustawienie PurgeChildEntries w zasadzie InvalidateCache powinno trwale usuwać tylko wartości elementu KeyFragment, ale czyści całą pamięć podręczną.

Obejście: użyj zasady KeyValueMapOperations, aby iterować obsługę wersji pamięci podręcznej i pominąć potrzebę unieważniania pamięci podręcznej.

• Apigee Edge obsługuje OpenAPI 3.0, gdy tworzysz specyfikacje w edytorze specyfikacji i publikujesz interfejsy API przy użyciu SmartDokumentów w portalu, ale niektóre funkcje nie są jeszcze obsługiwane.

  Na przykład te funkcje ze specyfikacji OpenAPI 3.0 nie są jeszcze obsługiwane:

  • Właściwości allOf służące do łączenia i rozszerzania schematów
  • Odwołania zdalne

  Jeśli specyfikacja OpenAPI odwołuje się do nieobsługiwanej funkcji, narzędzia w niektórych przypadkach ją zignorują, ale nadal będą renderować dokumentację API. W innych przypadkach nieobsługiwana funkcja spowoduje błędy, które uniemożliwią prawidłowe wyrenderowanie dokumentacji referencyjnej interfejsu API. W obu przypadkach musisz zmodyfikować specyfikację OpenAPI, aby uniknąć korzystania z nieobsługiwanej funkcji do czasu jej obsługi w kolejnej wersji.

  Uwaga: edytor specyfikacji jest mniej restrykcyjny niż aplikacja SmartDokumentacja w przypadku renderowania dokumentacji referencyjnej interfejsu API, dlatego wyniki poszczególnych narzędzi mogą się różnić.

• Gdy używasz w portalu tego interfejsu API, nagłówek Accept jest ustawiony na application/json niezależnie od wartości consumes ustawionej w specyfikacji OpenAPI.

• Jednoczesne aktualizowanie portalu (np. strony, motywu, arkusza CSS lub skryptu) przez wielu użytkowników nie jest obecnie obsługiwane.
• Jeśli usuniesz z portalu stronę dokumentacji API, nie będzie można jej ponownie utworzyć. Musisz usunąć i ponownie dodać usługę API oraz ponownie wygenerować dokumentację API.
• Podczas konfigurowania zasad bezpieczeństwa treści może minąć do 15 minut, zanim zmiany będą w pełni stosowane.
• Podczas dostosowywania motywu portalu zastosowanie wszystkich zmian może potrwać do 5 minut.

• W nadchodzącej wersji wyszukiwarka zostanie zintegrowana ze zintegrowanym portalem.

Węzły apigee-nginx w routerach brzegowych mogą zgłaszać problemy z wiązaniem portów lub zakończeniem procesu nginx.

Komponent: Edge-router

Problem: te problemy mogą być spowodowane błędami w możliwościach konfiguracji podczas instalacji usługi apigee-nginx.

Rozwiązanie: możesz ręcznie ustawić możliwości, wykonując to polecenie:

setcap CAP_NET_BIND_SERVICE=+ep CAP_KILL=+ep /opt/nginx/sbin/nginx

Ten problem dotyczy użytkowników, którzy próbują zainstalować logowanie jednokrotne lub nowy interfejs użytkownika w RHEL 8 z włączoną funkcją FIPS w Edge for Private Cloud 4.53.00.

Komponent, którego dotyczy problem: SSO i nowy interfejs użytkownika

Problem: jeśli instalujesz SSO lub nowe UI w systemie operacyjnym RHEL 8 z włączonym FIPS, instalacja się nie powiedzie.

Obejście: zalecamy używanie klasycznego interfejsu, który jest kompletny i spełnia wymagania dotyczące funkcjonalności interfejsu.

Ten problem dotyczy tylko użytkowników, którzy korzystają z MINT lub mają włączoną tę usługę w instalacjach Edge for Private Cloud.

Komponent, którego dotyczy problem: edge-message-processor

Problem: jeśli masz włączoną monetyzację i instalujesz wersję 4.52.01 jako nową lub aktualizujesz poprzednią wersję Private Cloud, napotkasz problem z procesorami wiadomości. Liczba otwartych wątków będzie stopniowo wzrastać, co doprowadzi do wyczerpania zasobów. W pliku system.log w procesie edge-message-processor pojawia się ten wyjątek:

Error injecting constructor, java.lang.OutOfMemoryError: unable to create new native thread

W wielu implementacjach protokołu HTTP/2 (CVE-2023-44487), w tym w Apigee Edge for Private Cloud, wykryto ostatnio podatność na atak typu DoS. Ta luka może prowadzić do ataku typu DoS na funkcję zarządzania interfejsami API Apigee. Więcej informacji znajdziesz w biuletynie o zabezpieczeniach Apigee GCP-2023-032.

Komponenty routera i serwera zarządzania Edge for Private Cloud są dostępne w internecie i mogą być potencjalnie podatne na zagrożenia. Mimo że protokół HTTP/2 jest włączony na porcie zarządzania innych komponentów Edge w Edge dla prywatnej chmury, żaden z tych komponentów nie jest dostępny w internecie. W przypadku komponentów innych niż Edge, takich jak Cassandra, Zookeeper i inne, HTTP/2 nie jest włączone. Aby rozwiązać problem z luką w Edge dla Private Cloud, wykonaj te czynności:

• Etapy konfiguracji Edge for Private Cloud w wersji 4.51.00.11 lub nowszej
• Etapy dotyczące wersji Edge for Private Cloud starszych niż 4.51.00.11

Jeśli używasz Edge Private Cloud w wersji 4.51.00.11 lub nowszej, wykonaj te czynności:

1. Aktualizowanie serwera zarządzania:

   1. Na każdym węźle serwera zarządzania otwórz /opt/apigee/customer/application/management-server.properties
   2. Dodaj ten wiersz do pliku właściwości:

      conf_webserver_http2.enabled=false

   3. Ponownie uruchom komponent serwera zarządzania:

      apigee-service edge-management-server restart

2. Zaktualizuj procesor wiadomości:

   1. Na każdym węźle procesora wiadomości otwórz /opt/apigee/customer/application/message-processor.properties
   2. Dodaj ten wiersz do pliku właściwości:

      conf_webserver_http2.enabled=false

   3. Ponownie uruchom komponent procesora wiadomości:

      apigee-service edge-message-processor restart

3. Aktualizowanie routera:

   1. Na każdym routerze otwórz /opt/apigee/customer/application/router.properties
   2. Dodaj ten wiersz do pliku właściwości:

      conf_webserver_http2.enabled=false

   3. Ponownie uruchom komponent procesora wiadomości:

      apigee-service edge-router restart

4. Aktualizowanie QPID:

   1. Na każdym węźle QPID otwórz /opt/apigee/customer/application/qpid-server.properties
   2. Dodaj ten wiersz do pliku właściwości:

      conf_webserver_http2.enabled=false

   3. Ponownie uruchom komponent procesora wiadomości:

      apigee-service edge-qpid-server restart

5. Aktualizacja Postgres:

   1. Na każdym węźle Postgres otwórz /opt/apigee/customer/application/postgres-server.properties
   2. Dodaj ten wiersz do pliku właściwości:

      conf_webserver_http2.enabled=false

   3. Ponownie uruchom komponent procesora wiadomości:

      apigee-service edge-postgres-server restart

Jeśli używasz Edge for Private Cloud w wersji starszej niż 4.51.00.11, wykonaj te czynności:

1. Aktualizowanie serwera zarządzania:

   1. Na każdym węźle serwera zarządzania otwórz /opt/apigee/customer/application/management-server.properties
   2. Dodaj do pliku właściwości te 2 wiersze:

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Ponownie uruchom komponent serwera zarządzania:

      apigee-service edge-management-server restart

2. Zaktualizuj procesor wiadomości:

   1. Na każdym węźle procesora wiadomości otwórz /opt/apigee/customer/application/message-processor.properties
   2. Dodaj do pliku właściwości te 2 wiersze:

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Ponownie uruchom komponent procesora wiadomości:

      apigee-service edge-message-processor restart

3. Aktualizowanie routera:

   1. Na każdym routerze otwórz /opt/apigee/customer/application/router.properties
   2. Dodaj do pliku właściwości te 2 wiersze:

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Ponownie uruchom komponent procesora wiadomości:

      apigee-service edge-router restart

4. Aktualizowanie QPID:

   1. Na każdym węźle QPID otwórz /opt/apigee/customer/application/qpid-server.properties
   2. Dodaj do pliku właściwości te 2 wiersze:

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Ponownie uruchom komponent procesora wiadomości:

      apigee-service edge-qpid-server restart

5. Aktualizacja Postgres:

   1. Na każdym węźle Postgres otwórz /opt/apigee/customer/application/postgres-server.properties
   2. Dodaj do pliku właściwości te 2 wiersze:

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Ponownie uruchom komponent procesora wiadomości:

      apigee-service edge-postgres-server restart

W przypadku usługi Apigee-postgresql występują problemy z aktualizacją z wersji 4.50 lub 4.51 Edge for Private Cloud do wersji 4.52. Problemy występują głównie wtedy, gdy liczba tabel przekracza 500.

Łączną liczbę tabel w Postgres możesz sprawdzić, wykonując to zapytanie SQL:

select count(*) from information_schema.tables

Rozwiązanie: jeśli aktualizujesz Apigee Edge 4.50.00 lub 4.51.00 na 4.52.00, przed uaktualnieniem Apigee-postgresql wykonaj krok wstępny.

apigee-mirror nie działa w systemie Red Hat Enterprise Linux (RHEL) 8.0.

Obejście: jako obejście problemu zainstaluj apigee-mirror na serwerze z wersją RHEL lub innym obsługiwanym systemem operacyjnym dla Apigee. Następnie możesz użyć lustra, aby dodać pakiety, nawet jeśli zainstalowałeś Apigee na serwerach RHEL 8.0.

149245401: Ustawienia puli połączeń LDAP dla JNDI skonfigurowane za pomocą zasobu LDAP nie są odzwierciedlane, a domyślne wartości JNDI powodują, że połączenia są używane tylko raz. W rezultacie połączenia są otwierane i zamykane za każdym razem, gdy są używane, co powoduje dużą liczbę połączeń z serwerem LDAP na godzinę.

Obejście:

Aby zmienić właściwości puli połączeń LDAP, wykonaj te czynności, aby wprowadzić zmianę globalną we wszystkich zasadach LDAP.

1. Utwórz plik właściwości konfiguracji, jeśli jeszcze nie istnieje:

   /opt/apigee/customer/application/message-processor.properties

2. Dodaj do pliku te informacje (zastąp wartości właściwości interfejsu JNDI (Java Naming and Directory Interface) zgodnie z wymaganiami konfiguracji zasobu LDAP).

   bin_setenv_ext_jvm_opts="-Dcom.sun.jndi.ldap.connect.pool.maxsize=20
   -Dcom.sun.jndi.ldap.connect.pool.prefsize=2
   -Dcom.sun.jndi.ldap.connect.pool.initsize=2
   -Dcom.sun.jndi.ldap.connect.pool.timeout=120000
   -Dcom.sun.jndi.ldap.connect.pool.protocol=ssl"

3. Upewnij się, że plik /opt/apigee/customer/application/message-processor.properties należy do użytkownika apigee:apigee.
4. Uruchom ponownie każdy procesor wiadomości.

Aby sprawdzić, czy właściwości JNDI puli połączeń zaczęły działać, możesz wykonać polecenie tcpdump, aby obserwować zachowanie puli połączeń LDAP na przestrzeni czasu.

139051927: Wysokie opóźnienia przetwarzania przez serwer proxy znalezione w przetwarzaczu wiadomości wpływają na wszystkie serwery proxy interfejsu API. Objawy to opóźnienia w przetwarzaniu o 200–300 ms w porównaniu z normalnym czasem odpowiedzi interfejsu API. Mogą one występować losowo nawet przy niskim wskaźniku TPS. Może się to zdarzyć, gdy ponad 50 celowych serwerów, z którymi łączą się procesory wiadomości,

Przyczyna źródłowa: procesory wiadomości przechowują pamięć podręczną, która mapuje adres URL docelowego serwera na obiekt HTTPClient na potrzeby połączeń wychodzących na serwery docelowe. Domyślnie to ustawienie jest skonfigurowane jako 50, co może być za niskie w przypadku większości wdrożeń. Jeśli w ramach wdrożenia występuje wiele kombinacji organizacji/środowiska, a liczba docelowych serwerów przekracza 50, adresy URL docelowych serwerów są stale usuwane z pamięci podręcznej, co powoduje opóźnienia.

Weryfikacja: Aby sprawdzić, czy usuwanie adresu URL serwera docelowego powoduje problem z opóźnieniem, przeszukaj pliki system.logs usługi Message Processor pod kątem obecności słowa kluczowego „onEvict” lub „Eviction”. Ich obecność w dziennikach wskazuje, że adresy URL docelowych serwerów są usuwane z pamięci podręcznej HTTPClient, ponieważ jej rozmiar jest zbyt mały.

Rozwiązanie: w przypadku Edge for Private Cloud w wersjach 19.01 i 19.06 możesz edytować i konfigurować pamięć podręczną HTTPClient: /opt/apigee/customer/application/message-processor.properties

conf/http.properties+HTTPClient.dynamic.cache.elements.size=500

Następnie uruchom ponownie przetwarzanie wiadomości. Wprowadź te same zmiany we wszystkich przetwarzaczach wiadomości.

Wartość 500 to przykład. Optymalna wartość dla Twojej konfiguracji powinna być większa niż liczba docelowych serwerów, z którymi ma się łączyć procesor wiadomości. Ustawienie tej właściwości na wyższy poziom nie powoduje żadnych skutków ubocznych. Jedynym efektem będzie skrócenie czasu przetwarzania żądań proxy przez procesor wiadomości.

Uwaga: w Edge dla Private Cloud w wersji 50.00 domyślnie ustawiona jest wartość 500.

157933959: jednoczesne wstawianie i aktualizowanie tej samej mapy klucz-wartość (KVM) ograniczonej do poziomu organizacji lub środowiska powoduje niespójność danych i utratę aktualizacji.

Uwaga: to ograniczenie dotyczy tylko Edge for Private Cloud. Edge dla chmury publicznej i hybrydowej nie ma tego ograniczenia.

Aby obejść ten problem w Edge for Private Cloud, utwórz KVM w zakresie apiproxy.