Ta strona została przetłumaczona przez Cloud Translation API.

Dane nie wyświetlają się w panelach statystyk

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

Krótki opis problemu

Panele statystyk (Wydajność serwera proxy, Docelowa wydajność itp.) nie wyświetlają żadnych danych w interfejsie Edge. We wszystkich panelach wyświetla się ten komunikat:

No traffic in the selected date range

Komunikaty o błędach

Ten problem nie powoduje dostrzegalnych błędów.

Możliwe przyczyny

W tabeli poniżej znajdziesz możliwe przyczyny tego problemu:

Przyczyna	Dla:
Brak ruchu API w środowisku organizacji	Edge dla użytkowników chmury prywatnej
Dane są dostępne w bazie danych Postgres, ale nie są wyświetlane w interfejsie	Edge dla użytkowników chmury prywatnej
Dane Analytics nie są przekazywane do bazy danych Postgres	Edge dla użytkowników chmury prywatnej
Nieprawidłowe wdrożenie Analytics	Edge dla użytkowników chmury prywatnej
Identyfikatory UUID serwera nieaktualnego serwera Analytics	Edge dla użytkowników chmury prywatnej

Brak ruchu API w środowisku organizacji

Diagnostyka

Sprawdź, czy serwery proxy interfejsu API w określonym środowisku organizacji są aktywne przez okres, w którym próbujesz wyświetlić dane analityczne, korzystając z jednej z tych metod:
1. Włącz śledzenie wszystkich interfejsów API, które są obecnie używane przez użytkowników, i sprawdź, czy w logu czasu pojawiają się żądania.
  Uwaga: UWAGA: ta metoda jest przydatna tylko wtedy, gdy chcesz sprawdzić, czy w przeszłości zamiast o danej chwili był ruch.
2. Wyświetl logi dostępu NGINX (/opt/apigee/var/log/edge-router/nginx/logs/access.log) i sprawdź, czy są nowe wpisy dla serwerów proxy interfejsu API dla określonego czasu trwania).
3. Jeśli rejestrujesz informacje z serwerów proxy interfejsu API na serwerze logów, takim jak Syslog, Splunk, Loggly itp., możesz sprawdzić, czy na tych serwerach logów znajdują się jakieś wpisy dla serwerów proxy API dla danego okresu.
Jeśli przez określony czas nie ma ruchu (brak żądań do interfejsu API), dane analityczne są niedostępne. W panelu statystyk zobaczysz komunikat „Brak ruchu w wybranym zakresie dat”.

Rozdzielczość

Wykonaj wywołania co najmniej 1 serwera proxy interfejsu API w określonym środowisku organizacji.
Odczekaj kilka sekund, a następnie wyświetl panele statystyk na karcie Godzina i sprawdź, czy pojawią się dane.
Jeśli problem będzie się powtarzać, przejdź do sekcji Dane dostępne w bazie danych Postgres, ale nie są wyświetlane w UI.

Dane są dostępne w bazie danych Postgres, ale nie są wyświetlane w interfejsie użytkownika

Krótki opis problemu

Najpierw określ dostępność najnowszych danych Analytics w bazie danych Postgres.

Aby sprawdzić, czy w węźle głównym Postgres są dostępne najnowsze dane Analytics:

Zaloguj się do każdego z serwerów Postgres i uruchom to polecenie, aby sprawdzić, czy jesteś w głównym węźle Postgres:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-master
```

W węźle głównym Postgres zaloguj się w PostgreSQL:

psql -h /opt/apigee/var/run/apigee-postgresql -U apigee apigee

Sprawdź, czy tabela istnieje dla Twojego środowiska-organizacji, korzystając z tego zapytania SQL w bazie danych Postgres:
```
\d analytics."orgname.envname.fact"
```
UWAGA: zastąp orgname i envname nazwami organizacji i środowiska.
Sprawdź, czy najnowsze dane są dostępne w bazie danych Postgres, korzystając z tego zapytania SQL:
```
select max(client_received_start_timestamp) from analytics."orgname.envname.fact";
```
Jeśli najnowsza sygnatura czasowa jest bardzo stara (lub ma wartość null), oznacza to, że dane nie są dostępne w bazie danych Postgres. Prawdopodobną przyczyną tego problemu jest to, że dane nie są przekazywane z serwera Qpid do bazy danych Postgres. Przejdź do artykułu Dane Analytics nie są przekazywane do bazy danych Postgres.
Jeśli najnowsze dane są dostępne w bazie danych Postgres w węźle głównym, wykonaj poniższe czynności, aby zdiagnozować przyczynę niewyświetlania danych w interfejsie Edge.

Diagnostyka

Włącz Narzędzia dla deweloperów w przeglądarce Chrome i uzyskaj interfejs API z jednego z paneli Analytics. Aby to zrobić:
1. W Narzędziach dla deweloperów wybierz kartę Network (Sieć).
2. Rozpocznij nagrywanie.
3. Załaduj ponownie panel Analytics.
4. W panelu po lewej stronie w Narzędziach dla programistów wybierz wiersz z "apiproxy?_optimized...".
5. W panelu po prawej stronie w Narzędziach dla programistów kliknij kartę „Nagłówki” i zanotuj „URL żądania”.
Oto przykładowe dane wyjściowe z Narzędzi dla programistów:
Przykładowe dane wyjściowe pokazujące interfejs API używany w panelu wydajności serwera proxy z karty Sieć w panelu narzędzi dla programistów do wydajności serwera proxy

Uruchom bezpośrednio wywołanie interfejsu API zarządzania i sprawdź, czy otrzymasz wyniki. Oto przykładowe wywołanie interfejsu API dla karty Dzień w panelu wydajności serwera proxy:

curl -u username:password
  "http://management_server_IP_address:8080/v1/organizations/
  org_name/environments/env_name/stats/apiproxy?limit=14400&
  select=sum(message_count),sum(is_error),avg(total_response_time),
  avg(target_response_time)&sort=DESC&sortby=sum(message_count),sum(is_error),
  avg(total_response_time),avg(target_response_time)&timeRange=08%2F9%2F2017+
  18:00:00~08%2F10%2F2017+18:00:00&timeUnit=hour&tsAscending=true"

Jeśli zostanie wyświetlona odpowiedź pomyślna, ale bez żadnych danych, oznacza to, że serwer zarządzania nie może pobrać danych z serwera Postgres z powodu problemów z połączeniem sieciowym.
Sprawdź, czy możesz połączyć się z serwerem Postgres z poziomu serwera zarządzania:
```
telnet Postgres_server_IP_address 5432
```
Jeśli nie możesz połączyć się z serwerem Postgres, sprawdź, czy na porcie 5432 obowiązują ograniczenia zapory sieciowej.
Jeśli istnieją ograniczenia zapory sieciowej, może to być przyczyną braku możliwości pobrania danych z serwera Postgres przez serwer zarządzania.

Rozdzielczość

Jeśli istnieją ograniczenia zapory sieciowej, usuń je, aby serwer zarządzania mógł komunikować się z serwerem Postgres.
Jeśli nie ma ograniczeń zapory sieciowej, problem może być spowodowany usterką sieci.
Jeśli na serwerze zarządzania wystąpiła awaria sieci, ponowne uruchomienie serwera może rozwiązać problem.
Ponownie uruchom wszystkie serwery zarządzania pojedynczo przy użyciu tego polecenia:
```
/opt/apigee/apigee-service/bin/apigee-service edge-management-server restart
```
Sprawdź, czy widzisz dane analityczne w interfejsie Edge.

Jeśli nadal nie widzisz danych, skontaktuj się z zespołem pomocy Apigee Edge.

Dane Analytics nie są przekazywane do bazy danych Postgres

Diagnostyka

Jeśli dane nie są przekazywane z serwera Qpid do bazy danych Postgres zgodnie z opisem w sekcji Dane dostępne w bazie danych Postgres, ale nie są wyświetlane w interfejsie, wykonaj te czynności:

Sprawdź, czy każdy serwer Qpid jest włączony, wykonując to polecenie:
```
/opt/apigee/bin/apigee-service edge-qpid-server status
```
Jeśli którykolwiek z serwerów Qpid przestanie działać, uruchom go ponownie. Jeśli nie, przejdź od razu do kroku 5.
```
/opt/apigee/bin/apigee-service edge-qpid-server restart
```
Zaczekaj trochę, a potem ponownie sprawdź, czy najnowsze dane są dostępne w bazie danych Postgres.
1. Zaloguj się w PostgreSQL:
```
psql -h /opt/apigee/var/run/apigee-postgresql -U apigee apigee
```
2. Uruchom to zapytanie SQL, aby sprawdzić, czy są dostępne najnowsze dane:
```
select max(client_received_start_timestamp) from analytics."orgname.envname.fact";
```
Jeśli najnowsze dane są dostępne, pomiń poniższe kroki i przejdź do ostatniego kroku w sekcji Rozwiązanie. Jeśli najnowsze dane są niedostępne, wykonaj te czynności.
Sprawdź, czy wiadomości z kolejek serwera Qpid są przekazywane do bazy danych Postgres.
1. Uruchom qpid-stat -q command i sprawdź wartości w kolumnach msgIn i msgOut.
2. Oto przykładowe dane wyjściowe, które pokazują, że wartości msgIn i msgOut są różne. Wskazuje to, że wiadomości nie są przekazywane z serwera Qpid do bazy danych Postgres.
Jeśli wartości w kolumnach msgIn i msgOut są różne, sprawdź logi serwera Qpid /opt/apigee/var/log/edge-qpid-server/system.log i zobacz, czy nie ma błędów.

Możesz zobaczyć komunikaty o błędach, takie jak „Prawdopodobnie PG nadal nie działa” lub „KRYTYCZNY: przepraszam, za dużo klientów”, tak jak to widać na ilustracji poniżej:

2017-07-28 09:56:39,896 ax-q-axgroup001-persistpool-thread-3
  WARN c.a.a.d.c.ServerHandle - ServerHandle.logRetry() : Found the exception to be
  retriable - . Error observed while trying to connect to
  jdbc:postgresql://PG_IP_address:5432/apigee Initial referenced UUID when
  execution started in this thread was a1ddf72f-ac77-49c0-a1fc-d0db6bf9991d
  Probably PG is still down. PG set used - [a1ddf72f-ac77-49c0-a1fc-d0db6bf9991d]
2017-07-28 09:56:39,896 ax-q-axgroup001-persistpool-thread-3
  WARN c.a.a.d.c.ServerHandle - ServerHandle.logRetry() : Could not get JDBC Connection;
  nested exception is org.postgresql.util.PSQLException: FATAL: sorry, too many clients already
2017-07-28 09:56:53,617 pool-7-thread-1
  WARN c.a.a.d.c.ServerHandle - ServerHandle.logRetry() : Found the exception to be
  retriable - . Error observed while trying to connect to
  jdbc:postgresql://PG_IP_address:5432/apigee
  Initial referenced UUID when execution started in this thread was
  a1ddf72f-ac77-49c0-a1fc-d0db6bf9991d Probably PG is still down. PG set used -
  [a1ddf72f-ac77-49c0-a1fc-d0db6bf9991d]
2017-07-28 09:56:53,617 pool-7-thread-1
  WARN c.a.a.d.c.ServerHandle - ServerHandle.logRetry() : Could not get JDBC Connection;
  nested exception is org.apache.commons.dbcp.SQLNestedException: Cannot create
  PoolableConnectionFactory (FATAL: sorry, too many clients already)

Może się tak zdarzyć, jeśli serwer Postgres wykonuje zbyt wiele zapytań SQL lub procesor jest bardzo wysoki, przez co nie może odpowiedzieć na serwer Qpid.

Rozdzielczość

Ponownie uruchom serwer Postgres i PostgreSQL, jak pokazano poniżej:

/opt/apigee/bin/apigee-service edge-postgres-server restart

/opt/apigee/bin/apigee-service apigee-postgresql restart

Ponowne uruchomienie gwarantuje, że wszystkie poprzednie zapytania SQL zostaną zatrzymane i powinno umożliwić nowe połączenia z bazą danych Postgres.
Załaduj ponownie panele informacyjne Analytics i sprawdź, czy wyświetlają się dane Analytics.

Jeśli problem będzie nadal występował, skontaktuj się z zespołem pomocy Apigee Edge.

Nieprawidłowe wdrożenie Analytics

Diagnostyka

Uzyskaj stan wdrożenia Analytics, korzystając z tego wywołania interfejsu API:

curl -u user_email:password http://management_server_host:port
/v1/organizations/orgname/environments/envname/provisioning/axstatus

W wynikach wywołania interfejsu API sprawdź stan serwerów Qpid i Postgres.
1. Jeśli stan serwerów Qpid i Postgres jest oznaczony jako „SUCCESS”, oznacza to, że serwery analityczne są prawidłowo podłączone. Przejdź do sekcji UUID użytkownika nieaktualnego serwera Analytics.
2. Jeśli stan serwerów Qpid/Postgres wyświetla się jako „UNKNOWN” lub „FAILURE”, oznacza to, że występuje problem z odpowiednim serwerem.
  Na przykład ten scenariusz pokazuje stan serwerów Postgres jako „UNKNOWN”:
  
  Może się tak zdarzyć, jeśli podczas wprowadzania statystyk wystąpi błąd. Ten błąd uniemożliwia wiadomości z serwerów zarządzania docierające do serwerów Postgres.

Rozdzielczość

Zwykle można rozwiązać ten problem przez ponowne uruchomienie serwerów, które spowodowały wystąpienie błędu „FAILURE” lub „UNKNOWN”.

Ponownie uruchom każdy z serwerów, których okablowanie Analytics wskazuje na „FAILURE” lub „UNKNOWN”, korzystając z tego polecenia:
```
/opt/apigee/apigee-service/bin/apigee-service component restart
```
Na przykład:
1. Jeśli problem występuje na serwerach Qpid, uruchom ponownie serwery Qpid:
```
/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server restart
```
2. Jeśli problem występuje na serwerach Postgres, uruchom ponownie zarówno główny, jak i podrzędny węzeł serwera Postgres:
```
/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server restart
```
W tym przykładzie w przypadku serwerów Postgres wyświetlany jest komunikat „UNKNOWN”, więc musisz ponownie uruchomić zarówno główny, jak i podrzędny serwer Postgres:
```
/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server restart
```

Nieaktualne identyfikatory UUID serwera Analytics

Diagnostyka

Pobierz konfigurację Analytics za pomocą tego wywołania interfejsu API:

curl -u user_email:password http://management-server-host:port/v1/analytics/groups/ax

Oto przykładowe dane wyjściowe uzyskane przez powyższy interfejs API:

[ {
  "name" : "axgroup001",
  "properties" : {
    "consumer-type" : "ax"
  },
  "scopes" : [ "myorg~prod", "myorg~test" ],
  "uuids" : {
    "aries-datastore" : [ ],
    "postgres-server" : [ "6777...2db14" ],
    "dw-server" : [ ],
    "qpid-server" : [ "774e...fb23", "29f3...8c11" ]
  },
  "consumer-groups" : [ {
    "name" : "consumer-group-001",
    "consumers" : [ "774e...8c11" ],
    "datastores" : [ "6777...db14" ],
    "properties" : {
    }
  } ],
  "data-processors" : {
  }
} ]

Upewnij się, że te informacje w danych wyjściowych są prawidłowe:
1. nazwy org-env wymienione w elemencie „zakresy”.
2. Identyfikatory UUID serwerów Postgres i Qpid.
  - Uzyskaj identyfikatory UUID serwera Postgres, uruchamiając to polecenie w każdym z węzłów serwera Postgres:
```
curl 0:8084/v1/servers/self/uuid
```
  - Uzyskaj identyfikatory UUID serwera Qpid, uruchamiając to polecenie w każdym z węzłów serwera Qpid:
```
curl 0:8083/v1/servers/self/uuid
```
Jeśli wszystkie informacje są poprawne, przejdź do artykułu Dane Analytics nie są przekazywane do bazy danych Postgres.
Jeśli identyfikatory UUID serwerów Postgres lub Qpid są nieprawidłowe, może to oznaczać, że serwery zarządzania odnoszą się do nieaktualnych identyfikatorów UUID.

Rozdzielczość

Aby usunąć nieaktualne identyfikatory UUID i dodać prawidłowe identyfikatory UUID serwerów, skontaktuj się z zespołem pomocy Apigee Edge.