Monitoring serwerów aplikacyjnych

[ArturB]

Monitoring serwerów aplikacyjnych
Częstym problemem do monitorowania jest monitoring tzw. serwerów aplikacyjnych, a w zasadzie maszyny wirtualnej Javy. Przyjrzymy się uniwersalnemu projektowi i jego możliwościom. Projekt ten to jolokia. Jest to JSON JMX Agent, który ma kilka zalet. Między innymi jest wydajny, ale także jest jest przyjazny firewallom jako że może korzystać z używa protokołu http.
Autorzy potwierdzają, że przeprowadzili pomyślne testy na różnych wersjach JBossa, WebLogica, Glassfisha, Websphere’a, Tomcata, Jetty, Resin, Jonas, Geronimo, Spring dm Server i Virgo. Także omawiany przez nas temat będzie dość popularny.
Sama instalacja jest dość prosta i zajmuje kilka sekund. Ze względu na to że nie znam samej technologii wybór padł na testy na Apache Tomcat 7.0. Proces instalacji polegał na pobraniu z jolokia.org pliku i deploy w Web GUI. Na stronie autorów znajdziemy informację że wystarczy go wrzucić do katalogu webapps na serwerze, tam też później się udałem celem zmienienia nazwy aplikacji z jolokia-war-1.1.2 na jolokia – o dziwo taka zmiana działa.
Oczywiście nie musimy się chwalić wszystkim stanem naszego serwera. Edytując webapps/WEB-INF/web.xml możemy po prostu odkomentować fragment:
KOD: ZAZNACZ CAŁY

Code:

  <security-constraint>
    <web-resource-collection>
      <web-resource-name>Jolokia-Agent Access</web-resource-name>
      <url-pattern>/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
      <role-name>Jolokia</role-name>
    </auth-constraint>
  </security-constraint>
 
  <security-role>
    <role-name>Jolokia</role-name>
  </security-role>

A następnie utworzyć użytkownika na danym serwerze o danej roli. W naszym przypadku w conf/tomcat-users.xml dopisujemy:
KOD: ZAZNACZ CAŁY

Code:

<user username="username" password="password" roles=" Jolokia" />

Nasz agent już działa, dlatego zajmiemy się teraz instalacją klienta. Wybór padł na check_jmx4perl . Główny powód to brak konieczności instalacji Javy na serwerze monitorującym. Drugim powodem jest sposób instalacji
KOD: ZAZNACZ CAŁY

Code:

#cpan –i JMX::Jmx4Perl

I część która jest niejako decydująca:
KOD: ZAZNACZ CAŁY

Code:

Jmx4Perl comes with a set of supporting scripts, which
are not necessarily required for using JMX::Jmx4Perl
programmatically.
 
jmx4perl
========
 
jmx4perl is a command line utility for accessing Jolokia agents
(www.jolokia.org). It can be used for script based exploration
and easy inspection of the JMX space.
 
Install 'jmx4perl' ? (y/n) [y ]y
 
check_jmx4perl
==============
 
check_jmx4perl is a full featured Nagios Plugin (www.nagios.org) for
monitoring JEE and other Java-servers.
 
Install 'check_jmx4perl' ? (y/n) [y ]y
 
cacti_jmx4perl
==============
 
cacti_jmx4perl is a script which can be used as a Cacti
(www.cacti.net) plugin.
 
Install 'cacti_jmx4perl' ? (y/n) [y ]n
 
j4psh
=====
 
j4psh is an interactive JMX shell with context sensitive command line
completion. It uses JMX::Jmx4Perl for connecting to the JMX backend
and has quite some Perl module dependencies.
 
Install 'j4psh' ? (y/n) [y ]y
 
jolokia
=======
 
jolokia is an utility which helps in downloading
and managing the Jolokia agents (www.jolokia.org), which
are required on the server side for using jmx4perl.
 
Install 'jolokia' ? (y/n) [y ]n

A po instalacji mamy dwie możliwości korzystania z check_jmx4perl.
Przykłady komend w starym stylu:
Uptime w ms - weryfikacja czy serwer jest w stanie się uruchomić
KOD: ZAZNACZ CAŁY

Code:

# check_jmx4perl --url http://127.0.0.1:8080/jolokia-war-1.1.2 --alias RUNTIME_UPTIME  --warning 120: --critical 60:
OK - [RUNTIME_UPTIME] : Value 553645 in range | [RUNTIME_UPTIME]=553645;120:;60:

Wielkość sterty
KOD: ZAZNACZ CAŁY

Code:

# check_jmx4perl --url http://127.0.0.1:8080/jolokia-war-1.1.2 --alias MEMORY_HEAP_USED --base-alias MEMORY_HEAP_MAX  --warning 80 --critical 90
OK - [MEMORY_HEAP_USED] : In range 1.66% (10318752 / 620756992) | [MEMORY_HEAP_USED]=10318752;496605593.6;558681292.8;0;620756992

Wielkość stosu
KOD: ZAZNACZ CAŁY

Code:

# check_jmx4perl --url http://127.0.0.1:8080/jolokia-war-1.1.2 --alias MEMORY_NONHEAP_USED --base-alias MEMORY_NONHEAP_MAX  --warning 80 --critical 90
OK - [MEMORY_HEAP_USED] : In range 1.66% (10318752 / 620756992) | [MEMORY_HEAP_USED]=10318752;496605593.6;558681292.8;0;620756992

SWAP
KOD: ZAZNACZ CAŁY

Code:

# check_jmx4perl --url http://127.0.0.1:8080/jolokia-war-1.1.2 --alias OS_MEMORY_SWAP_FREE --base-alias OS_MEMORY_SWAP_TOTAL   --warning 90: --critical 80:
OK - [OS_MEMORY_SWAP_FREE] : In range 100.00% (4227850240 / 4227850240) | [OS_MEMORY_SWAP_FREE]=4227850240;3805065216:;3382280192:;0;4227850240

Ilość rozpoczętych wątków w ciągu ostatnich 60s
KOD: ZAZNACZ CAŁY

Code:

# check_jmx4perl --url http://127.0.0.1:8080/jolokia-war-1.1.2 --alias THREAD_COUNT_STARTED --delta 60  --warning 50 --critical 90
OK - [THREAD_COUNT_STARTED] : Value 0 in range | [THREAD_COUNT_STARTED]=0;50;90

Ilość wątków
KOD: ZAZNACZ CAŁY

Code:

# check_jmx4perl --url http://127.0.0.1:8080/jolokia-war-1.1.2 --alias THREAD_COUNT  --warning 50 --critical 90
OK - [THREAD_COUNT] : Value 14 in range | [THREAD_COUNT]=14;50;90

Klasy
KOD: ZAZNACZ CAŁY

Code:

# check_jmx4perl --url http://127.0.0.1:8080/jolokia-war-1.1.2 --alias CL_LOADED  --warning 2500 --critical 3000
OK - [CL_LOADED] : Value 2064 in range | [CL_LOADED]=2064;2500;3000

Te przykłady zostały zrealizowane w starej notacji, dodatkowo nie musimy używać aliasów:
KOD: ZAZNACZ CAŁY

Code:

check_jmx4perl --url http://localhost:8888/jolokia \
                --name memory_used \
                --mbean java.lang:type=Memory \
                --attribute HeapMemoryUsage \
                --path used \
                --critical 10000000 \
                --warning   5000000

W celu wyświetlenia wszystkich możliwych aliasów
KOD: ZAZNACZ CAŁY

Code:

check_jmx4perl aliases

Na czym polega jednak nowa notacja
na tworzeniu plików konfiguracyjnych, zawierających opis serwerów:
KOD: ZAZNACZ CAŁY

Code:

<Server lokalny>
Url http://127.0.0.1:8080/jolokia-war-1.1.2
User tomcat
Password password
</Server>

Przypominamy sobie konfigurację jolokia, która umożliwia wymuszenie autentyfikacji.
i konfigurację checków - przykład z labs.consol.de

KOD: ZAZNACZ CAŁY

Code:

# Hosts
include servers.cfg
 
# Default definitions
include default/memory.cfg
include default/tomcat.cfg
include default/threads.cfg
 
# ====================================
# Check definitions
 
<Check j4p_memory_heap>
  Use memory_heap
  Critical 90
  Warning 80
</Check>
 
<Check j4p_thread_count>
  Use thread_count
  Critical 1000
  Warning 800
</Check>
 
# Check for uptime, used as kind of 'ping' for 
# service dependencies
<Check j4p_uptime>
  MBean java.lang:type=Runtime
  Attribute Uptime
  Warning 120:
  Critical 60:
</Check>
 
# A multi check combining two checks
<MultiCheck j4p_jvm>
  Check j4p_memory_heap
  Check j4p_thread_count
</Check>
 
# ===========================================
# Tomcat Apps
# -----------
 
<Check app_sessions>
  Use tc_session_active($0)
  Critical 1000
  Warning 800
</Check>
 
<Check app_servlet_requests>
  Use tc_servlet_requests($0)
  Critical 6000
  Warning 5000
</Check>
 
# Multicheck for a webapp
# $0: Web-Application name (e.g. "j4p")
# $1: Servlet-Name (e.g. "j4p-agent")
<MultiCheck app_all>
  Check app_sessions($0)
  Check app_servlet_requests($1)
</MultiCheck>
 
# Connector related multicheck
<MultiCheck connector_all>
  Check tc_connector_threads($0)
  Check tc_connector_received_rate($0)
  Check tc_connector_sent_rate($0)
  Check tc_connector_processing_time($0)
  Check tc_connector_requests($0)
  Check tc_connector_error_count($0)
</MultiCheck>

teraz wywołanie sprowadza się do jednej nagiosowej komendy:
KOD: ZAZNACZ CAŁY

Code:

command_line check_jmx4perl --config /opt/plugins/custom/emca/jmx4perl/jmx4perl.cfg --server lokalny --check Check_albo_MultiCheck Opcjonalne Argumenty.

Myślę że wspólnie zgodzimy się że każde podejście ma swoje dobre strony. Dla mnie, jako osoby która ma szczątkową wiedzę na temat aplikacji Javowych stary sposób wydaje się jaśniejszy, niewymagający dodatkowych plików.

W tym momencie myślę że zostało powiedziane dość sporo na temat monitoringu JVM.

---

Temat monitorowania serwerów aplikacji JEE jest coraz częściej poruszany przez naszych klientów. Z tego też powodu, chce pokazać realizację tego problemu na przykładzie gotowych serwisów w op5 monitorze wykorzystując technologię Java Management Extensions (JMX).

   

Przyjrzyjmy się niektórym prezentowanym wartościom.

Pierwszą z nich bez wątpienia jest uptime. Na pierwszy rzut oka można by zapytać po co nam taka informacja. 

   

Odpowiedź w przypadku tej technologii jest stosunkowo prosta. Nieobsłużone wyjątki i inne błędy w aplikacji mogą powodować restarty maszyny wirtualnej. Jeśli maszyna restartuje się co jakiś czas dobrze abyśmy o tym wiedzieli.

A dlaczego pozostałe parametry? Każdy kto miał styczność z Javą, ma pewne, słuszne skojarzenia. Na pierwszym miejscu zapewne są klasy, bo Java jest idealnym przykładem języka zorientowanego obiektowo. Dlatego też monitorujemy ilość załadowanych klas.

   

Kolejną cechą technologii jest wielowątkowość. Dlatego monitorujemy ilość wątków, a także ilość nowych wątków w określonym czasie.

   

   

w naszym przypadku maszyna służy jedynie prezentacji przez co nie otwiera nowych wątków

Ostatnim skojarzeniem programisty powinny być dwa obszary pamięci, którymi jest stos i sterta. W przypadku Javy nie ma możliwości utworzenia obiektu na stosie (który również monitorujemy), dlatego przedstawiam wykres zajętości sterty.