Tworzenie raportów niestandardowych

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

Raporty niestandardowe umożliwiają szczegółowe analizowanie konkretnych danych interfejsu API i wyświetlanie dokładnie tych danych, które chcesz zobaczyć. Na panelach monitorowania interfejsu API możesz utworzyć raport niestandardowy z filtrem i danymi wstępnie ustawionymi na podstawie skonfigurowanych warunków w momencie tworzenia. Dodatkowo w raporcie jest skonfigurowany zestaw domyślnych wymiarów i danych.

Tworzenie raportu niestandardowego na podstawie kontekstu

Szybko twórz raporty niestandardowe na podstawie kontekstu, jak podsumowano w tabeli poniżej. Na stronie Raporty niestandardowe raporty niestandardowe utworzone za pomocą monitorowania interfejsu API mają unikalne nazwy (domyślnie), jak wskazano w tabeli. Możesz zmienić nazwę podczas edytowania raportu niestandardowego.

Domyślne wymiary i dane

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

Edytowanie raportu niestandardowego

Jak wspomnieliśmy w poprzedniej sekcji, w raportach niestandardowych jest wstępnie skonfigurowany predefiniowany zestaw domyślnych wymiarów i danych monitorowania interfejsu API. Po utworzeniu raportu niestandardowego możesz go edytować, aby dodawać lub usuwać dane i wymiary. Możesz na przykład zawęzić analizę do konkretnego tokena dostępu, aplikacji dewelopera, serwera proxy interfejsu API lub identyfikatora żądania.

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

Poniższy przykład dodaje do raportu niestandardowego wymiar Client ID. Wymiar Client ID zawiera klucz klienta (klucz interfejsu API) dewelopera wywołującego interfejs API, niezależnie od tego, czy jest on przekazywany w żądaniu jako klucz interfejsu API, czy jest zawarty w tokenie OAuth:

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

Więcej informacji o wszystkich predefiniowanych wymiarach i danych, które możesz dodać do raportu, znajdziesz w artykule Dane, wymiary i filtry Analytics.

W następnym przykładzie dodajesz filtr do raportu niestandardowego, który rejestruje domyślne dane i wymiary dla 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: używanie raportów niestandardowych do diagnozowania problemów z wdrożeniem

Dołącz zasadę StatisticsCollector do serwerów proxy interfejsu API, aby zbierać niestandardowe dane Analytics, takie jak identyfikator użytkownika lub produktu, cena, działanie REST, wersja docelowa, adres URL docelowy i długość wiadomości. Dane mogą pochodzić ze zmiennych przepływu wstępnie zdefiniowanych przez Apigee, nagłówków żądań, parametrów zapytania lub zmiennych niestandardowych, które zdefiniujesz.

Na przykład żądania do serwera proxy interfejsu API zawierają nagłówki z identyfikatorem produktu, identyfikatorem użytkownika i wersją serwera docelowego. To żądanie 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 w nagłówkach, aby zdiagnozować problemy z serwerem proxy interfejsu API podczas działania.

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

1. Dodaj do interfejsu API zasadę StatisticsCollector, aby rejestrować wartość nagłówków niestandardowych:

   <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 poczekaj, aż będzie można uzyskać do niego dostęp.

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

   

4. Aby wyświetlić więcej szczegółów w prawym okienku ostatniego panelu, wybierz wiersz serwera proxy myapi.

5. W prawym okienku ostatniego panelu kliknij > Wyświetl w analizie, aby otworzyć panel analizy:

   

6. Odfiltruj panel analizy według serwera proxy myapi , a następnie wyświetl Kod stanu na wykresie u góry. Zauważ, że występują błędy 403 i 501:

   

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

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

9. Wybierz Błędy proxy jako dane i ustaw Funkcję agregacji na Suma. W razie potrzeby możesz dodać więcej danych.

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

    

11. Ustaw filtr tak, aby zawierał tylko dane serwera proxy interfejsu API myapi (apiproxy eq 'myapi'):

    

12. Zapisz raport.

13. Uruchom raport za ostatnie 24 godziny. Gdy raport otworzy się po raz pierwszy, 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. Na przykład wybierasz 403:

    

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

    

16. Aby wyświetlić błędy według użytkownika, w sekcji Podsumowanie kliknij wersję docelową: