Znane problemy z Apigee

Gdy zmienna przepływu cachehit jest używana po polityce LookupCache, ze względu na sposób wysyłania punktów debugowania w przypadku zachowania asynchronicznego, polityka LookupPolicy wypełnia obiekt DebugInfo przed wykonaniem wywołania zwrotnego, co powoduje błąd.

Obejście: powtórz proces (nawiązywanie drugiego połączenia) bezpośrednio po pierwszym połączeniu.

Ustawienie wartości PurgeChildEntries w zasadzie InvalidateCache powinno spowodować usunięcie tylko wartości elementu KeyFragment, ale powoduje wyczyszczenie całej pamięci podręcznej.

Rozwiązanie: użyj polityki KeyValueMapOperations, aby iterować wersjonowanie pamięci podręcznej i ominąć konieczność unieważniania pamięci podręcznej.

Może się tak zdarzyć, gdy równolegle działają różne wersje potoku wdrożeniowego CI/CD. Aby uniknąć tego problemu, nie wdrażaj zasobów proxy API ani SharedFlow przed zakończeniem bieżącego wdrożenia.

Rozwiązanie: unikaj jednoczesnego wdrażania proxy interfejsu API i SharedFlow.

Interfejs Edge API Analytics może czasami zawierać zduplikowane dane wywołań interfejsu API. W takim przypadku liczby wywołań interfejsu API wyświetlane w Edge API Analytics są wyższe niż porównywalne wartości wyświetlane w zewnętrznych narzędziach analitycznych.

Rozwiązanie: wyeksportuj dane analityczne i użyj pola gateway_flow_id, aby usunąć duplikaty.

• Apigee Edge obsługuje specyfikację OpenAPI 3.0, gdy tworzysz specyfikacje za pomocą edytora specyfikacji i publikujesz interfejsy API za pomocą SmartDocs w portalu, choć część funkcji nie jest jeszcze obsługiwana.

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

  • allOfwłaściwości do łączenia i rozszerzania schematów
  • odwołania zdalne.

  Jeśli w specyfikacji OpenAPI jest nawiązanie do funkcji, której nie obsługujemy, narzędzia mogą ją zignorować, ale nadal renderować dokumentację referencyjną interfejsu API. W innych przypadkach nieobsługiwana funkcja spowoduje błędy, które uniemożliwią renderowanie dokumentacji referencyjnej interfejsu API. W obu przypadkach musisz zmodyfikować specyfikację OpenAPI, aby uniknąć używania funkcji, która nie jest obsługiwana, dopóki nie zostanie obsługiwana w przyszłej wersji.

  Uwaga: podczas renderowania dokumentacji referencyjnej interfejsu API edytor specyfikacji jest mniej restrykcyjny niż SmartDocs, więc wyniki uzyskane za pomocą tych narzędzi mogą się różnić.

• Gdy używasz opcji Wypróbuj ten interfejs API na portalu, nagłówek Accept jest ustawiony na application/json niezależnie od wartości consumes w specyfikacji OpenAPI.
• 138438484: Wiele serwerów nie jest obsługiwanych.

• Jednoczesne aktualizowanie portalu (np. strony, motywu, szablonu CSS lub skryptu) przez wielu użytkowników nie jest obecnie obsługiwane.
• Jeśli usuniesz stronę dokumentacji referencyjnej API z portalu, nie będzie można jej ponownie utworzyć. Musisz usunąć i ponownie dodać produkt API, a następnie wygenerować dokumentację referencyjną API.
• Podczas konfigurowania zasad bezpieczeństwa treści pełne zastosowanie zmian może potrwać do 15 minut.
• Gdy dostosujesz motyw portalu, wprowadzenie zmian może potrwać do 5 minut.

• Wyszukiwarka zostanie zintegrowana z integrowanym portalem w jednej z kolejnych wersji.

Ten problem dotyczy tylko użytkowników, którzy korzystają z MINT lub mają włączoną tę usługę w Edge dla instalacji chmury prywatnej.

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

Problem: jeśli masz włączoną monetyzację i instalujesz wersję 4.52.01 jako nową instalację lub uaktualniasz ją z poprzednich wersji chmury prywatnej, 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 procesora komunikatów brzegowych widać 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 dla chmury prywatnej, wykryto niedawno lukę w zabezpieczeniach typu odmowa usługi (DoS). Ta luka w zabezpieczeniach może prowadzić do ataku typu DoS na funkcje zarządzania interfejsami API Apigee. Więcej informacji znajdziesz w biuletynie o zabezpieczeniach Apigee GCP-2023-032.

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

• Instrukcje dla Edge w chmurze prywatnej w wersji 4.51.00.11 lub nowszej
• Czynności w przypadku 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. Zaktualizuj serwer 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. Uruchom ponownie komponent procesora wiadomości:

      apigee-service edge-message-processor restart

3. Zaktualizuj router:

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

      conf_webserver_http2.enabled=false

   3. Uruchom ponownie komponent procesora wiadomości:

      apigee-service edge-router restart

4. Aktualizacja 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. Uruchom ponownie 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. Uruchom ponownie 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. Zaktualizuj serwer 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. Uruchom ponownie komponent procesora wiadomości:

      apigee-service edge-message-processor restart

3. Zaktualizuj router:

   1. Na każdym węźle routera 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. Uruchom ponownie komponent procesora wiadomości:

      apigee-service edge-router restart

4. Aktualizacja 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. Uruchom ponownie 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. Uruchom ponownie komponent procesora wiadomości:

      apigee-service edge-postgres-server restart

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

Aby sprawdzić łączną liczbę tabel w PostgreSQL, uruchom to zapytanie SQL:

select count(*) from information_schema.tables

Obejście: podczas aktualizowania Apigee Edge w wersji 4.50.00 lub 4.51.00 do wersji 4.52.00 przed uaktualnieniem Apigee-postgresql wykonaj krok wstępny.

149245401: ustawienia puli połączeń LDAP dla JNDI skonfigurowane za pomocą zasobu LDAP nie są odzwierciedlane, a ustawienia domyślne JNDI powodują, że za każdym razem używane są połączenia jednorazowe. W rezultacie połączenia są otwierane i zamykane za każdym razem do jednorazowego użytku, co powoduje dużą liczbę połączeń z serwerem LDAP w ciągu godziny.

Obejście:

Aby zmienić właściwości puli połączeń LDAP, wykonaj te czynności, aby wprowadzić globalną zmianę 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 wiersze (zastąp wartości właściwości Java Naming and Directory Interface (JNDI) 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ń działają prawidłowo, możesz wykonać tcpdump, aby obserwować zachowanie puli połączeń LDAP w czasie.

139051927: Wysokie opóźnienia przetwarzania serwera proxy w procesorze wiadomości mają wpływ na wszystkie serwery proxy interfejsu API. Objawy to opóźnienia w czasie przetwarzania o 200–300 ms w porównaniu z normalnym czasem odpowiedzi interfejsu API. Mogą one występować losowo nawet przy niskim TPS. Może to wystąpić, gdy liczba serwerów docelowych, z którymi łączy się procesor wiadomości, przekracza 50.

Przyczyna: Procesory wiadomości przechowują pamięć podręczną, która mapuje adres URL serwera docelowego na obiekt HTTPClient dla połączeń wychodzących z serwerami docelowymi. Domyślnie to ustawienie ma wartość 50, która w przypadku większości wdrożeń może być zbyt niska. Jeśli w konfiguracji wdrożenia występuje wiele kombinacji organizacji i środowiska, a łączna liczba serwerów docelowych przekracza 50, adresy URL serwerów docelowych są usuwane z pamięci podręcznej, co powoduje opóźnienia.

Weryfikacja: Aby sprawdzić, czy problem z opóźnieniem jest spowodowany usunięciem adresu URL serwera docelowego, wyszukaj w plikach system.logs procesora wiadomości słowa kluczowe „onEvict” lub „Eviction”. Ich obecność w logach wskazuje, że adresy URL serwera docelowego są usuwane z pamięci podręcznej HTTPClient, ponieważ jej rozmiar jest zbyt mały.

Obejście: 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 ponownie uruchom procesor wiadomości. Wprowadź te same zmiany we wszystkich procesorach wiadomości.

Wartość 500 jest tylko przykładem. Optymalna wartość w Twojej konfiguracji powinna być większa niż liczba serwerów docelowych, z którymi połączy się procesor wiadomości. Ustawienie wyższej wartości tej właściwości nie ma żadnych skutków ubocznych, a jedynym efektem będzie skrócenie czasu przetwarzania żądań proxy przez procesor wiadomości.

Uwaga: w przypadku Edge for Private Cloud w wersji 50.00 domyślne ustawienie to 500.

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

Uwaga: to ograniczenie dotyczy tylko Edge w chmurze prywatnej. Edge for Public Cloud i Hybrid nie mają tego ograniczenia.

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