Edge for Private Cloud w wersji 4.18.01
W produkcji zwykle trzeba włączyć mechanizmy monitorowania w ramach wdrożenia Apigee Edge for Private Cloud. 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 dotyczące monitorowania.
Dla ułatwienia komponenty Apigee są podzielone głównie na 2 kategorie:
- Usługi serwera Java specyficzne dla Apigee – obejmują one serwer zarządzania, procesor wiadomości, serwer Qpid i serwer Postgres.
- Usługi innych firm – np. Nginx Router, Apache Cassandra, Apache ZooKeeper, OpenLDAP, baza danych PostgreSQL i Qpid.
W przypadku wdrożenia na potrzeby firmy na potrzeby firmy w usłudze Apigee Edge w tabeli poniżej znajdziesz krótki opis parametrów, które możesz monitorować:
|
Składnik |
Sprawdzanie systemu |
Statystyki na poziomie procesu |
Sprawdzanie na poziomie interfejsu API |
Sprawdzanie przepływu wiadomości |
Szczegóły komponentu |
|
|---|---|---|---|---|---|---|
|
Usługi Java specyficzne dla Apigee |
Serwer zarządzania |
? |
? |
? |
||
|
procesor komunikatów |
? |
? |
? |
? |
||
|
Qpid Server |
? |
? |
? |
|||
|
Serwer Postgres |
? |
? |
? |
|||
|
Usługi zewnętrzne |
Apache Cassandra |
? |
? |
|||
|
Apache ZooKeeper |
? |
? |
||||
|
OpenLDAP |
? |
? |
||||
|
Baza danych PostgreSQL |
? |
? |
||||
|
Qpid |
? |
? |
||||
|
Nginx Router |
? |
? |
? |
|||
Po zainstalowaniu Apigee Edge możesz wykonywać te czynności monitorowania, aby śledzić wydajność instalacji Apigee Edge for Private Cloud.
Kontrole stanu systemu
Na wyższym poziomie bardzo ważne jest mierzenie parametrów stanu systemu, takich jak wykorzystanie procesora, wykorzystanie pamięci i możliwość łączenia się z portami. Aby uzyskać podstawowe informacje o stanie systemu, możesz monitorować te parametry:
- Wykorzystanie procesora – określa podstawowe statystyki (użytkownik/system/we/wy oczekiwanie/nieczynne) dotyczące wykorzystania procesora. Na przykład całkowite wykorzystanie procesora przez system.
- Wolna/wykorzystana 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.
- Średnia obciążenia – określa liczbę procesów oczekujących na wykonanie.
- Statystyki sieci – wysłane i otrzymane pakiety sieciowe lub bajty wraz z błędami przesyłania dotyczącymi określonego komponentu.
Procesy i sprawdzanie aplikacji
Na poziomie procesu możesz wyświetlać ważne informacje o wszystkich uruchomionych procesach. Obejmują one na przykład statystyki dotyczące wykorzystania pamięci i procesora przez proces lub aplikację. W przypadku procesów takich jak qpidd, postgres postmaster, java itp. możesz monitorować:
- Identyfikacja procesu: identyfikuj konkretny proces Apigee. Możesz na przykład sprawdzać, czy istnieje proces serwera Java Apigee.
- Statystyki wątku: możesz wyświetlić podstawowe wzorce wątkowania używane przez proces. Możesz na przykład monitorować liczbę szczytowych wątków i liczbę wątków dla wszystkich procesów.
- Wykorzystanie pamięci: możesz sprawdzić wykorzystanie pamięci przez wszystkie procesy Apigee. Możesz na przykład monitorować parametry takie jak użycie pamięci stosu i pamięci nienależącej do stosu przez proces.
Sprawdzanie na poziomie interfejsu API
Na poziomie interfejsu API możesz sprawdzać, czy serwer jest uruchomiony i czy działa prawidłowo w przypadku często używanych wywołań interfejsu API obsługiwanych przez Apigee. Możesz na przykład wykonać sprawdzenie interfejsu API na serwerze zarządzania, routerze i przetwarzaczu wiadomości, 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 wiadomości: 8082
- itd.
Informacje o uruchamianiu tego polecenia w przypadku poszczególnych komponentów znajdziesz w odpowiednich sekcjach poniżej
To wywołanie zwraca wartość „true” (prawda) lub „false” (fałsz). Aby uzyskać najlepsze wyniki, możesz też wysyłać wywołania interfejsu API bezpośrednio na backendzie (z którym współpracuje oprogramowanie Apigee), aby szybko określić, czy błąd występuje w środowisku oprogramowania Apigee, czy na backendzie.
Uwaga: do monitorowania serwerów proxy interfejsu API możesz też używać funkcji Stan interfejsu API w usłudze Apigee. Stan interfejsu API wykonuje zaplanowane wywołania do serwerów proxy interfejsu API i informuje, kiedy dochodzi do ich niepowodzenia i w jaki sposób. Gdy wywołania są udane, stan interfejsu API pokazuje czas odpowiedzi i może nawet wysyłać powiadomienia, gdy czas oczekiwania na odpowiedź jest długi. Interfejs API Google Health może wykonywać wywołania z różnych lokalizacji na świecie, aby porównać działanie interfejsu API w różnych regionach.
Sprawdzanie przepływu wiadomości
Możesz zbierać dane z Routerów i przetwarzaczy wiadomości dotyczące przepływu wiadomości wzorce/statystyki. Dzięki temu możesz monitorować te elementy:
- Liczba aktywnych klientów
- Liczba odpowiedzi (10x, 20x, 30x, 40x i 50x)
- Nieudane próby połączenia
Dzięki temu możesz udostępniać panele dotyczące przepływu wiadomości w interfejsie API. Więcej informacji:
- Jak monitorować przetwarzanie wiadomości
- Panel monitorowania Apigee w wersji beta: przegląd (Router)
Kontrola stanu routera w usłudze Message Processor
Router wdraża mechanizm kontroli stanu, aby określić, które z procesorów wiadomości działają zgodnie z oczekiwaniami. Jeśli wykryjemy, że procesor wiadomości działa wolno lub nie działa, możemy automatycznie wyjąć go z rotacji. W takiej sytuacji router zapisuje komunikaty „Mark Down” w pliku dziennika routera w katalogu /opt/apigee/var/log/edge-router/logs/system.log.
Możesz sprawdzać te komunikaty w pliku dziennika Routera. Jeśli na przykład router usunie przetwarzacz wiadomości z rotacji, zapisze w dzienniku wiadomość w formacie:
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 wiadomości.
Jeśli później Router przeprowadzi sprawdzanie stanu i ustali, że przetwarzacz wiadomości działa prawidłowo, automatycznie włączy go ponownie do rotacji. Router zapisuje też wiadomość „Mark Up” w dzienniku w formie:
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