Tworzenie raportów niestandardowych

Wyświetlasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. Informacje

Raporty niestandardowe umożliwiają zawężenie zakresu danych interfejsu API i wyświetlanie tylko tych informacji, które Cię interesują. Na panelach Monitorowanie interfejsu API możesz utworzyć raport niestandardowy z filtrem i wstępnie ustawionymi danymi na podstawie skonfigurowanych warunków w momencie jego tworzenia. W raporcie skonfigurowano też dla Ciebie zestaw wymiarów i danych domyślnych.

Tworzenie raportu niestandardowego na podstawie kontekstu

Możesz szybko tworzyć raporty niestandardowe na podstawie kontekstu, jak podano w tabeli poniżej. Na stronie Raporty niestandardowe raporty niestandardowe utworzone za pomocą Monitorowania interfejsu API mają unikalne nazwy (domyślnie), jak pokazano w tabeli. Możesz zmienić nazwę, gdy edytujesz raport niestandardowy.

Wymiar i dane domyślne

Raport niestandardowy będzie domyślnie zawierać wymiary i dane wymienione w tabeli poniżej w przypadku wszystkich raportów wygenerowanych przez Monitorowanie interfejsu API.

Edytowanie raportu niestandardowego

Jak wspomnieliśmy w poprzedniej sekcji, w raportach niestandardowych jest wstępnie skonfigurowany wstępnie zdefiniowany zestaw wymiarów i danych interfejsu API Monitoring. Po utworzeniu raportu niestandardowego możesz go edytować, aby w razie potrzeby dodawać i usuwać z niego dane i wymiary. Możesz na przykład zawęzić zakres prowadzonych działań do konkretnego tokena dostępu, aplikacji dewelopera, serwera proxy interfejsu API lub identyfikatora żądania.

W tym raporcie niestandardowym dodajesz zdefiniowany wstępnie wymiar Gateway Flow ID, w którym Gateway Flow ID zawiera unikalny identyfikator UUID każdego żądania interfejsu API wysłanego do Edge. Pamiętaj, że raport już używa wymiaru Request URI:

W tym przykładzie do raportu niestandardowego dodawany jest wymiar Client ID. Wymiar Client ID zawiera klucz konsumenta (klucz interfejsu API) dewelopera, który wysyła wywołanie interfejsu API, niezależnie od tego, czy jest on przekazywany w żądaniu jako klucz interfejsu API, czy jest uwzględniony w tokenie OAuth:

Raport niestandardowy zawiera informacje o wszystkich wartościach Client ID. W następnym przykładzie dodajemy filtr, aby utworzyć raport niestandardowy dla konkretnego Client ID:

Więcej informacji o wszystkich wstępnie zdefiniowanych wymiarach i danych, które możesz dodać do raportu, znajdziesz w artykule [GA4] Dane, wymiary i filtry Analytics – informacje.

W następującym przykładzie do raportu niestandardowego dodajesz filtr, który obejmuje domyślne dane i wymiary dotyczące kodu błędu policies.ratelimit.QuotaViolation i kodów stanu 5xx:

Szczegółowe informacje o edytowaniu raportu niestandardowego znajdziesz w artykule Zarządzanie raportami niestandardowymi.

Przykład: diagnozowanie problemów z wdrożeniem za pomocą raportów niestandardowych

Załącz do swoich serwerów proxy interfejsu API politykę StatisticsCollector, aby zbierać niestandardowe dane analityczne, takie jak identyfikator użytkownika lub produktu, cena, działanie REST, wersja docelowa, adres URL docelowy i długość wiadomości. Dane mogą pochodzić z zmiennych przepływu zdefiniowanych przez Apigee, nagłówków żądań, parametrów zapytań lub zdefiniowanych przez Ciebie zmiennych niestandardowych.

Na przykład żądania wysyłane do serwera proxy interfejsu API zawierają nagłówki identyfikatora produktu, identyfikatora użytkownika i wersji serwera docelowego. Prośba może mieć postać:

curl -H "prodid:123456" -H "userid:98765" -H "targetversion:beta" http://myapi.com/myapi

Następnie możesz użyć informacji z nagłówków, aby zdiagnozować problemy z proxy interfejsu API w czasie działania.

Aby utworzyć raport niestandardowy dla tych nagłówków:

1. Aby rejestrować wartości nagłówków niestandardowych, dodaj do swojego interfejsu API politykę StatisticsCollector:

   <StatisticsCollector name="publishPurchaseDetails">
     <Statistics>
       <Statistic name="prodid" ref="request.header.prodid" type="integer">0</Statistic>
       <Statistic name="userid" ref="request.header.userid" type="integer">0</Statistic>
       <Statistic name="targetversion" ref="request.header.targetversion" type="string">alpha</Statistic>
     </Statistics>
   </StatisticsCollector>

2. Wdróż serwer proxy i daj mu czas na udostępnienie.

3. Aby wyświetlić problemy z interfejsem API, w interfejsie Edge kliknij Analizuj > Monitorowanie interfejsu API > Ostatnie. Zwróć uwagę, że w przypadku serwera proxy myapi występują błędy 4xx i 5xx:

   

4. Wybierz wiersz proxy myapi, aby wyświetlić więcej szczegółów w prawym panelu na karcie Ostatnie.

5. Aby otworzyć panel zbadania, w prawym panelu panelu Ostatnie kliknij  > Wyświetl w Narzędziach:

   

6. Odfiltruj panel zbadania według serwera proxy myapi, a potem sprawdź kod stanu na wykresie u góry. Zwróć uwagę, że występują błędy 403 i 501:

   

7. W interfejsie Edge wybierz Analiza > Raporty niestandardowe > Raporty, aby utworzyć raport niestandardowy, który będzie zawierać wartości tych danych niestandardowych jako wymiar.

8. Aby utworzyć raport niestandardowy o nazwie myapi_errors, kliknij + Raport niestandardowy.

9. Jako Dane wybierz Błędy proxy, a jako Funkcja agregacji – Suma. W razie potrzeby możesz dodać więcej danych.

10. Wybierz wstępnie zdefiniowany wymiar Kod stanu odpowiedzi, a potem dodaj do wymiarów 3 statystyki niestandardowe: prodid, targetersion i userid:

    

11. Ustaw filtr tak, aby uwzględniał tylko dane z interfejsu proxy API myapi:(apiproxy eq 'myapi')

    

12. Zapisz raport.

13. Wygeneruj raport z ostatnich 24 godzin. Po pierwszym otwarciu raportu zobaczysz wykres błędów HTTP 403 i 501:

    

14. W sekcji Podsumowanie kliknij 403 lub 510, aby sprawdzić, który produkt generuje błędy. Wybierasz np. 403:

    

15. Aby wyświetlić błędy według wersji docelowej (alfa lub beta), kliknij identyfikator produktu w sekcji Podsumowanie:

    

16. Kliknij wersję docelową w sekcji Podsumowanie, aby wyświetlić błędy według użytkowników: