Antywzór: dodaj informacje niestandardowe do schematu należącego do Apigee w bazie danych Postgres

Przeglądasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. Informacje

Edge API Analytics to bardzo zaawansowana funkcja udostępniana przez Apigee Edge. Gromadzi i analizuje szeroki zakres danych przesyłanych przez interfejsy API. Zebrane dane analityczne mogą dostarczyć bardzo przydatnych informacji. Możesz na przykład sprawdzić, jaki jest trend ruchu w zakresie ruchu z interfejsu API w określonym czasie. Który interfejs API jest najczęściej używany? Które interfejsy API mają dużą liczbę błędów?

Regularna analiza tych danych i statystyk może służyć do podejmowania odpowiednich działań, takich jak planowanie wydajności interfejsów API w przyszłości na podstawie bieżącego wykorzystania, decyzji biznesowych i przyszłych inwestycji oraz wielu innych kwestii.

Dane Analytics i ich przechowywanie

Interfejs API Analytics rejestruje wiele różnych typów danych, np.:

  • Informacje o interfejsie API – identyfikator URI żądania, adres IP klienta, kody stanu odpowiedzi itd.
  • Wydajność serwera proxy interfejsu API – odsetek sukcesów/niepowodzeń, czas przetwarzania żądań i odpowiedzi itd.
  • Docelowa wydajność serwera – odsetek sukcesów/niepowodzeń, czas przetwarzania
  • Informacje o błędzie – liczba błędów, kod błędu, naruszenia zasad, liczba Apigee i serwer docelowy powodują błędy.
  • Inne informacje – liczba żądań przesłanych przez programistów, deweloperów itd.

Wszystkie te dane są przechowywane w schemacie analytics utworzonym i zarządzanym w bazie danych Postgres przez Apigee Edge.

Zwykle w przypadku instalacji wanillowej Edge Postgres ma następujące schematy:

Schemat o nazwie analytics jest używany przez Edge do przechowywania wszystkich danych analitycznych w każdej organizacji i środowisku. Jeśli zainstalowano zarabianie, będzie dostępny schemat rkms. Inne schematy są przeznaczone dla wewnętrznych mechanizmów Postgres.

Schemat analytics będzie się zmieniać, ponieważ Apigee Edge dynamicznie będzie dodawać do niego nowe tabele faktów w czasie działania. Komponent serwera Postgres zbierze dane faktów w tabelach zbiorczych, które są wczytywane i wyświetlane w interfejsie Edge.

Antywzór

Dodawanie niestandardowych kolumn, tabel lub widoków do dowolnych schematów należących do Apigee w Bazie danych Postgres w Private Cloud bezpośrednio za pomocą zapytań SQL nie jest zalecane, ponieważ może to mieć niepożądane konsekwencje.

Przyjrzyjmy się temu szczegółowo na przykładzie.

Rozważmy tabelę niestandardową o nazwie account utworzoną w schemacie analitycznym, jak pokazano poniżej:

Załóżmy po pewnym czasie, że trzeba uaktualnić Apigee Edge z niższej wersji do wyższej. Uaktualnienie Private Cloud Apigee Edge obejmuje uaktualnienie Postgres i wiele innych komponentów. Jeśli do bazy danych Postgres są dodane jakiekolwiek kolumny, tabele lub widoki niestandardowe, uaktualnienie Postgres zakończy się niepowodzeniem z powodu błędów odwołujących się do obiektów niestandardowych, ponieważ nie zostały one utworzone przez Apigee Edge. Z tego powodu uaktualnienie Apigee Edge również kończy się niepowodzeniem i nie można go ukończyć.

Podobnie błędy mogą występować podczas działań konserwacji Apigee Edge, gdy wykonywane są tworzenie i przywracanie kopii zapasowych komponentów Edge, w tym bazy danych Postgres.

Wpływ

  • Nie można ukończyć uaktualniania Apigee Edge, ponieważ uaktualnienie komponentu Postgres kończy się niepowodzeniem z powodu błędów dotyczących obiektów niestandardowych, które nie zostały utworzone przez Apigee Edge.
  • Niespójności (i awarie) podczas konserwacji usługi Apigee Analytics (kopii zapasowej/przywracania).

Sprawdzona metoda

  • Nie dodawaj żadnych niestandardowych informacji w postaci kolumn, tabel, widoków, funkcji ani procedur bezpośrednio do żadnego schematu należącego do Apigee, np. analytics itp.
  • Jeśli zajdzie potrzeba obsługi informacji niestandardowych, możesz dodać je jako kolumny (pola) przy użyciu zasady kolektora statystyk do schematu analytics.

Więcej informacji