Tworzenie raportów niestandardowych

Oglądasz dokumentację Apigee Edge.
Wyświetl dokumentację Apigee X.

Raporty niestandardowe umożliwiają bardziej szczegółowe analizowanie konkretnych wskaźników interfejsu API i wyświetlanie dokładnych danych, które Cię interesują. W panelach monitorowania interfejsu API możesz utworzyć raport niestandardowy z gotowymi ustawieniami filtra i wskaźników na podstawie skonfigurowanych warunków w czasie tworzenia. Dodatkowo w raporcie zostanie skonfigurowany zestaw domyślnych wymiarów i danych.

Utwórz raport niestandardowy na podstawie kontekstu

Szybko twórz raporty niestandardowe na podstawie kontekstu zgodnie z podsumowaniem w tabeli poniżej. Na stronie Raporty niestandardowe raporty niestandardowe, które są tworzone za pomocą monitorowania interfejsu API, domyślnie mają unikalne nazwy, które można wpisać w tabeli. Podczas edytowania raportu niestandardowego możesz zmienić jego nazwę.

Kontekst raportu niestandardowego Domyślna konwencja nazewnictwa raportów niestandardowych
Ostatni panel API Monitoring Recent Generated
Panel osi czasu API Monitoring Timeline Generated
Panel analizy API Monitoring Investigate Generated
Stan alertu API Monitoring Generated: alert-name

Wymiar domyślny i dane

Raport niestandardowy będzie domyślnie zawierał wymiary i dane wymienione w tabeli poniżej dotyczące wszystkich raportów generowanych za pomocą interfejsu API Monitoring.

Komponent Domyślne
Wymiary Identyfikator URI żądania
Dane
  • Całkowity czas odpowiedzi
  • Docelowy czas odpowiedzi
  • Błędy serwera proxy
  • Błędy docelowe

Edytowanie raportu niestandardowego

Jak wspomnieliśmy w poprzedniej sekcji, w raportach niestandardowych wstępnie skonfigurowano domyślne wymiary i dane interfejsu API Monitoring. Po utworzeniu raportu możesz go edytować, aby dodać lub usunąć dane i wymiary. Na przykład możesz zawęzić zakres analizy do konkretnego tokena dostępu, aplikacji programisty, serwera proxy interfejsu API lub identyfikatora żądania.

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

Poniższy przykład dodaje wymiar Client ID do raportu niestandardowego. 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 zawarty w tokenu OAuth:

Raport niestandardowy zawiera informacje dotyczące wszystkich wartości parametru Client ID. W następnym przykładzie dodaliśmy filtr, dzięki któremu możesz utworzyć raport niestandardowy dotyczący określonego klienta (Client ID):

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

W następnym przykładzie dodasz do raportu niestandardowego filtr, który będzie zbierać domyślne dane i wymiary kodów błędów policies.ratelimit.QuotaViolation i kodów stanu 5xx:

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

Przykład: korzystanie z raportów niestandardowych do diagnozowania problemów z wdrażaniem

Dołącz do zasad serwera proxy API zasady CollectCollect, aby zbierać niestandardowe dane statystyczne, takie jak identyfikator użytkownika lub produktu, cena, działanie REST, wersja docelowa, docelowy adres URL i długość wiadomości. Dane mogą pochodzić ze zmiennych przepływu określonych przez Apigee, nagłówków żądań, parametrów zapytania i 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. Żądanie może mieć postać:

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

Możesz skorzystać z informacji w nagłówkach, aby zdiagnozować problemy z czasem działania serwera proxy interfejsu API.

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

  1. Dodaj do interfejsu API zasady CollectionCollector, by 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 na dostęp.

  3. Aby wyświetlić problemy z interfejsem API, w interfejsie Edge kliknij Analyze > API Monitoring > Ostatni. 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 panelu po prawej stronie panelu Ostatnie.

  5. Aby uzyskać dostęp do panelu analizy, w prawym panelu panelu Ostatnie kliknij Menu Więcej > Wyświetl w narzędziu Zbadaj:

  6. Przefiltruj panel Analiza na podstawie serwera proxy myapi, a następnie wyświetl Kod stanu na górnym wykresie. Zwróć uwagę na błędy 403 i 501:

  7. W interfejsie użytkownika Edge wybierz kolejno Analytics > Raporty niestandardowe > Raporty, by utworzyć raport niestandardowy, który zawiera wartości tych danych niestandardowych jako wymiar.

  8. Kliknij + Raport niestandardowy, aby utworzyć raport niestandardowy o nazwie myapi_errors.

  9. Wybierz Błędy serwera proxy dla wskaźnika, a w funkcji zbiorczejustaw wartość Suma. Jeśli chcesz, 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 dotyczące serwera proxy myapiAPI(apiproxy eq 'myapi'):

  12. Zapisz raport.

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

  14. W sekcji Podsumowanie kliknij 403 lub 510, by sprawdzić, który produkt generuje błędy. Na przykład wybierzesz 403:

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

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