Edge dla chmury prywatnej w wersji 4.16.09
Zwykle w konfiguracji produkcyjnej konieczne jest włączenie mechanizmów monitorowania we wdrożeniu Apigee Edge dla chmury prywatnej. Te techniki monitorowania ostrzegają administratorów (lub operatorów) sieci o błędzie lub awarii. Każdy wygenerowany błąd jest zgłaszany jako alert w Apigee Edge. Więcej informacji o alertach znajdziesz w artykule Sprawdzone metody monitorowania.
Dla ułatwienia komponenty Apigee są podzielone głównie na 2 kategorie:
- Usługi serwera Java związane z Apigee – obejmują serwer zarządzania, procesor komunikatów, serwer Qpid i serwer Postgres.
- Usługi innych firm – obejmują router Nginx, Apache Cassandra, Apache ZooKeeper, OpenLDAP, bazę danych PostgreSQL i Qpid.
W przypadku wdrożenia Apigee Edge lokalnie w tabeli poniżej znajdziesz parametry, które możesz monitorować:
|
Komponent |
Kontrole systemu |
Statystyki na poziomie procesu |
Sprawdzanie poziomu interfejsu API |
Kontrole przepływu wiadomości |
Komponenty |
|
|---|---|---|---|---|---|---|
|
Usługi Java związane z Apigee |
Serwer zarządzania |
? |
? |
? |
||
|
procesor komunikatów |
? |
? |
? |
? |
||
|
Serwer Qpid |
? |
? |
? |
|||
|
Serwer Postgres |
? |
? |
? |
|||
|
Usługi innych firm |
Apache Cassandra |
? |
? |
|||
|
Apache ZooKeeper |
? |
? |
||||
|
OpenLDAP |
? |
? |
||||
|
Baza danych PostgreSQL |
? |
? |
||||
|
Qpid |
? |
? |
||||
|
Router Nginx |
? |
? |
? |
|||
Po zainstalowaniu Apigee Edge możesz wykonywać te zadania monitorowania, aby śledzić wydajność instalacji Apigee Edge dla chmury prywatnej.

Kontrole stanu systemu
Bardzo ważne jest, aby mierzyć parametry stanu systemu, takie jak wykorzystanie procesora, wykorzystanie pamięci i połączenia z portami, na wyższym poziomie. Aby uzyskać podstawowe informacje o stanie systemu, możesz monitorować te parametry.
- Wykorzystanie procesora – określa podstawowe statystyki (użytkownik/system/oczekiwanie na operacje wejścia-wyjścia/bezczynność) dotyczące wykorzystania procesora. Na przykład łączna ilość procesora używana przez system.
- Free/Used Memory (Wolna/używana pamięć) – określa wykorzystanie pamięci systemowej w bajtach. Na przykład pamięć fizyczna używana przez system.
- Wykorzystanie miejsca na dysku – określa informacje o systemie plików na podstawie bieżącego wykorzystania dysku. Na przykład miejsce na dysku twardym używane przez system.
- Średnie obciążenie – określa liczbę procesów oczekujących na uruchomienie.
- Statystyki sieci – pakiety sieciowe lub bajty przesłane i odebrane wraz z błędami transmisji dotyczącymi określonego komponentu.
Kontrole procesów i aplikacji
Na poziomie procesu możesz wyświetlić ważne informacje o wszystkich uruchomionych procesach. Obejmują one na przykład statystyki użytkowania pamięci i procesora przez proces lub aplikację. W przypadku procesów takich jak qpidd, postgres postmaster, java itp. możesz monitorować te elementy:
- Identyfikacja procesu: identyfikowanie konkretnego procesu Apigee. Możesz na przykład monitorować istnienie procesu Java serwera Apigee.
- Statystyki wątków: wyświetl podstawowe wzorce wątków używane przez proces. Możesz na przykład monitorować szczytową liczbę wątków i liczbę wątków we wszystkich procesach.
- Wykorzystanie pamięci: wyświetl wykorzystanie pamięci przez wszystkie procesy Apigee. Możesz na przykład monitorować parametry takie jak wykorzystanie pamięci sterty i pamięci innej niż sterta przez proces.
Kontrole na poziomie interfejsu API
Na poziomie interfejsu API możesz sprawdzać, czy serwer działa w przypadku często używanych wywołań interfejsu API, które są przekazywane przez Apigee. Możesz na przykład sprawdzić interfejs API na serwerze zarządzania, routerze i procesorze komunikatów, wywołując to polecenie cURL:
curl http://<host>:<port>/v1/servers/self/up
Gdzie <host> to adres IP komponentu Apigee Edge. Numer <port> jest specyficzny dla każdego komponentu Edge. Na przykład:
Serwer zarządzania: 8080
- Router: 8081
- Procesor komunikatów: 8082
- itd.
W sekcjach poniżej znajdziesz informacje o uruchamianiu tego polecenia dla poszczególnych komponentów.
To wywołanie zwraca wartości „true” i „false”. Aby uzyskać najlepsze wyniki, możesz też wywoływać interfejsy API bezpośrednio w backendzie (z którym współdziała oprogramowanie Apigee), aby szybko ustalić, czy błąd występuje w środowisku oprogramowania Apigee czy w backendzie.
Uwaga: do monitorowania serwerów proxy interfejsów API możesz też używać funkcji API Health w Apigee. Stan interfejsu API wykonuje zaplanowane wywołania serwerów proxy interfejsów API i powiadamia Cię, gdy się nie powiodą, oraz informuje, jak do tego doszło. Gdy wywołania się powiodą, stan interfejsu API pokazuje czasy odpowiedzi, a nawet może powiadomić Cię, gdy czas oczekiwania na odpowiedź jest długi. API Health może wykonywać wywołania z różnych lokalizacji na świecie, aby porównywać zachowanie interfejsu API w różnych regionach.
Sprawdzanie przepływu wiadomości
Możesz zbierać dane z routerów i procesorów komunikatów dotyczące wzorców i statystyk przepływu komunikatów. Dzięki temu możesz monitorować:
- Liczba aktywnych klientów
- Liczba odpowiedzi (10X, 20X, 30X, 40X i 50X)
- Błędy połączenia
Dzięki temu możesz udostępniać panele informacyjne dotyczące przepływu komunikatów interfejsu API.
Kontrola stanu routera procesora komunikatów
Router implementuje mechanizm kontroli stanu, aby określić, które procesory komunikatów działają zgodnie z oczekiwaniami. Jeśli router wykryje, że procesor komunikatów nie działa lub działa wolno, może automatycznie wyłączyć go z rotacji. W takim przypadku router zapisuje komunikat „Mark Down” w pliku dziennika routera w lokalizacji /<inst root>/apigee4/var/log/apigee/router/logs/system.log.
Możesz monitorować plik dziennika routera pod kątem tych komunikatów. Jeśli na przykład router wyłączy procesor komunikatów z rotacji, zapisze komunikat w dzienniku w postaci:
2014-05-06 15:51:52,159 org: env: RPCClientClientProtocolChildGroup-RPC-0 INFO CLUSTER - ServerState.setState() : State of 2a8a0e0c-3619-416f-b037-8a42e7ad4577 is now DISCONNECTED. handle = <MP_IP> at 1399409512159 2014-04-17 12:54:48,512 org: env: nioEventLoopGroup-2-2 INFO HEARTBEAT - HBTracker.gotResponse() : No HeartBeat detected from /<MP_IP>:<PORT> Mark Down
gdzie /<MP_IP>:<PORT> to adres IP i numer portu procesora komunikatów.
Jeśli później router przeprowadzi kontrolę stanu i stwierdzi, że procesor komunikatów działa prawidłowo, automatycznie przywróci go do rotacji. Router zapisuje też w dzienniku komunikat „Mark Up” w formacie:
2014-05-06 16:07:29,054 org: env: RPCClientClientProtocolChildGroup-RPC-0 INFO CLUSTER - ServerState.setState() : State of 2a8a0e0c-3619-416f-b037-8a42e7ad4577 is now CONNECTED. handle = <IP> at 1399410449054 2014-04-17 12:55:06,064 org: env: nioEventLoopGroup-4-1 INFO HEARTBEAT - HBTracker.updateHB() : HeartBeat detected from /<IP>:<PORT> Mark Up
Aby skonfigurować router do przeprowadzania kontroli stanu, ustaw tę właściwość na true w pliku /<inst root>/apigee4/conf/apigee/router/router.properties:
Client.pool.heartBeat.use.http=true
Następnie ponownie uruchom router:
> /<inst-root>/apigee4/bin/apigee-service router restart