Wyświetlasz dokumentację Apigee Edge.
Otwórz dokumentację
Apigee X. info
Edge API Analytics to bardzo zaawansowana wbudowana funkcja udostępniana przez Apigee Edge. Zbiera i analizuje szeroki zakres danych przepływających przez interfejsy API. Przechwycone dane analityczne mogą dostarczyć bardzo przydatnych informacji. Na przykład: jak zmienia się w czasie natężenie ruchu w interfejsie API? Który interfejs API jest najczęściej używany? Które interfejsy API mają wysoki wskaźnik błędów?
Regularna analiza tych danych i informacji może posłużyć do podejmowania odpowiednich działań, takich jak przyszłe planowanie przepustowości interfejsów API na podstawie bieżącego wykorzystania, decyzji biznesowych i przyszłych inwestycji, oraz wielu innych.
Dane analityczne i ich przechowywanie
Interfejs API Analytics rejestruje wiele różnych typów danych, takich jak:
- informacje o interfejsie API – identyfikator URI żądania, adres IP klienta, kody stanu odpowiedzi itp.;
- skuteczność proxy interfejsu API – wskaźnik sukcesu/niepowodzenia, czas przetwarzania żądania i odpowiedzi itp.;
- skuteczność serwera docelowego – wskaźnik sukcesu/niepowodzenia, czas przetwarzania;
- informacje o błędach – liczba błędów, kod błędu, zasada powodująca błąd, liczba błędów spowodowanych przez Apigee i serwer docelowy spowodowane błędy;
- inne informacje – liczba żądań wysyłanych przez deweloperów, aplikacje deweloperów itp.
Wszystkie te dane są przechowywane w analytics schemacie utworzonym i zarządzanym w
bazie danych Postgres przez Apigee Edge.
Zwykle w czystej instalacji Edge Postgres będzie mieć te schematy:
Schemat o nazwie analytics jest używany przez Edge do przechowywania wszystkich danych analitycznych dla
każdej organizacji i środowiska. Jeśli zainstalowana jest monetyzacja, będzie też schemat rkms. Pozostałe schematy są przeznaczone na potrzeby wewnętrzne Postgres.
Schemat analytics będzie się zmieniać, ponieważ Apigee Edge będzie dynamicznie dodawać do niego nowe tabele faktów
w czasie działania. Komponent serwera Postgres będzie agregować dane faktów w tabele zbiorcze
, które są wczytywane i wyświetlane w nowym interfejsie Edge.
Antywzorzec
Dodawanie kolumn niestandardowych, tabel lub widoków do dowolnego schematu należącego do Apigee w bazie danych Postgres w środowiskach chmury prywatnej bezpośrednio za pomocą zapytań SQL jest niewskazane, ponieważ może mieć negatywne konsekwencje.
Aby to szczegółowo wyjaśnić, rozważmy przykład.
Załóżmy, że w schemacie analitycznym została utworzona tabela niestandardowa o nazwie account (konto), jak
pokazano poniżej:
Po pewnym czasie może się okazać, że trzeba zaktualizować Apigee Edge z niższej wersji do wyższej wersji. Aktualizacja Apigee Edge w chmurze prywatnej obejmuje aktualizację Postgres i wielu innych komponentów. Jeśli do bazy danych Postgres dodano kolumny niestandardowe, tabele lub widoki, aktualizacja Postgres nie powiedzie się i wyświetli błędy odwołujące się do obiektów niestandardowych, ponieważ nie zostały one utworzone przez Apigee Edge. W związku z tym aktualizacja Apigee Edge też się nie powiedzie i nie będzie można jej ukończyć.
Podobne błędy mogą wystąpić podczas czynności konserwacyjnych Apigee Edge, w których wykonywane są kopie zapasowe i przywracanie komponentów Edge, w tym bazy danych Postgres.
Wpływ
- Nie można ukończyć aktualizacji Apigee Edge, ponieważ aktualizacja komponentu Postgres nie powiedzie się i wyświetli błędy odwołujące się do obiektów niestandardowych, które nie zostały utworzone przez Apigee Edge.
- Niespójności (i awarie) podczas konserwacji usługi Apigee Analytics (tworzenie kopii zapasowych i przywracanie).
Sprawdzona metoda
- Nie dodawaj żadnych informacji niestandardowych w postaci kolumn, tabel, widoków, funkcji i
procedur bezpośrednio do żadnego schematu należącego do Apigee, np.
analytics. - Jeśli trzeba obsługiwać informacje niestandardowe, można je dodać jako kolumny (pola) za pomocą
zasady Statistics Collector do
analyticsschematu.