13 JMX agent

Przegląd

Monitorowanie JMX może być używane do monitorowania liczników JMX aplikacji Java.

Monitorowanie JMX ma natywne wsparcie w Zabbix w postaci demona Zabbix o nazwie „Zabbix Java gateway”.

Aby pobrać wartość konkretnego licznika JMX na hoście, serwer Zabbix odpytuje Java gateway Zabbix, który z kolei używa API zarządzania JMX do zdalnego odpytywania interesującej aplikacji.

Więcej szczegółów oraz informacje o konfiguracji można znaleźć w sekcji Zabbix Java gateway.

Włączanie zdalnego monitorowania JMX dla aplikacji Java

Aplikacja Java nie wymaga instalacji żadnego dodatkowego oprogramowania, ale musi zostać uruchomiona z opcjami wiersza poleceń podanymi poniżej, aby obsługiwać zdalne monitorowanie JMX.

Jako absolutne minimum, jeśli chcesz po prostu rozpocząć monitorowanie prostej aplikacji Java na lokalnym hoście bez wymuszonych zabezpieczeń, uruchom ją z następującymi opcjami:

java \
-Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.port=12345 \
-Dcom.sun.management.jmxremote.authenticate=false \
-Dcom.sun.management.jmxremote.ssl=false \
-Dcom.sun.management.jmxremote.registry.ssl=false \
-jar /path/to/your/application.jar

Spowoduje to, że Java będzie nasłuchiwać przychodzących połączeń JMX na porcie 12345, wyłącznie z lokalnego hosta, oraz nie będzie wymagać uwierzytelniania ani SSL.

Jeśli chcesz zezwolić na połączenia na innym interfejsie, ustaw parametr -Djava.rmi.server.hostname na adres IP tego interfejsu.

Jeśli chcesz bardziej rygorystycznie podejść do kwestii bezpieczeństwa, masz do dyspozycji wiele innych opcji Java. Na przykład kolejny przykład uruchamia aplikację z bardziej wszechstronnym zestawem opcji i udostępnia ją w szerszej sieci, a nie tylko na lokalnym hoście.

java \
-Djava.rmi.server.hostname=192.168.3.14 \
-Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.port=12345 \
-Dcom.sun.management.jmxremote.authenticate=true \
-Dcom.sun.management.jmxremote.password.file=/etc/java-6-openjdk/management/jmxremote.password \
-Dcom.sun.management.jmxremote.access.file=/etc/java-6-openjdk/management/jmxremote.access \
-Dcom.sun.management.jmxremote.ssl=true \
-Dcom.sun.management.jmxremote.registry.ssl=true \
-Djavax.net.ssl.keyStore=$YOUR_KEY_STORE \
-Djavax.net.ssl.keyStorePassword=$YOUR_KEY_STORE_PASSWORD \
-Djavax.net.ssl.trustStore=$YOUR_TRUST_STORE \
-Djavax.net.ssl.trustStorePassword=$YOUR_TRUST_STORE_PASSWORD \
-Dcom.sun.management.jmxremote.ssl.need.client.auth=true \
-jar /path/to/your/application.jar

Większość (jeśli nie wszystkie) z tych ustawień można określić w pliku $JRE/lib/management/management.properties (lub tam, gdzie ten plik znajduje się w twoim systemie).

Zwróć uwagę, że jeśli chcesz używać SSL, musisz zmodyfikować skrypt startup.sh, dodając opcje -Djavax.net.ssl.* do Java gateway, aby wiedział, gdzie znaleźć magazyny kluczy i zaufania.

Szczegółowy opis znajduje się w Monitoring and Management Using JMX.

Konfigurowanie interfejsów JMX i pozycji w frontend Zabbix

Gdy Java gateway jest uruchomiony, serwer wie, gdzie go znaleźć, a aplikacja Java została uruchomiona z obsługą zdalnego monitorowania JMX, nadszedł czas, aby skonfigurować interfejsy i pozycje w GUI Zabbix.

Konfigurowanie interfejsu JMX

Zacznij od utworzenia interfejsu typu JMX na interesującym Cię hoście.

Wszystkie obowiązkowe pola wejściowe są oznaczone czerwoną gwiazdką.

Dodawanie pozycji agenta JMX

Dla każdego licznika JMX, który chcesz monitorować, dodajesz pozycję agent JMX przypisaną do tego interfejsu.

Klucz na zrzucie ekranu poniżej to jmx["java.lang:type=Memory","HeapMemoryUsage.used"].

Wszystkie obowiązkowe pola wejściowe są oznaczone czerwoną gwiazdką.

Pola wymagające określonych informacji dla pozycji JMX to:

Jeśli chcesz monitorować licznik logiczny, który przyjmuje wartość „true” albo „false”, ustaw typ informacji na „Numeric (unsigned)” i wybierz krok przetwarzania wstępnego „Boolean to decimal” na karcie Preprocessing. Serwer będzie przechowywać wartości logiczne odpowiednio jako 1 lub 0.

Klucze pozycji JMX bardziej szczegółowo

Proste atrybuty

Nazwa obiektu MBean jest po prostu ciągiem znaków, który definiujesz w swojej aplikacji Java. Z kolei nazwa atrybutu może być bardziej złożona. Jeśli atrybut zwraca prymitywny typ danych (liczbę całkowitą, ciąg znaków itp.), nie ma się czym martwić — klucz będzie wyglądał tak:

jmx[com.example:Type=Hello,weight]

W tym przykładzie nazwa obiektu to „com.example:Type=Hello”, nazwa atrybutu to „weight”, a typ zwracanej wartości powinien prawdopodobnie być ustawiony na „Numeric (float)”.

Atrybuty zwracające dane złożone

Sytuacja staje się bardziej skomplikowana, gdy atrybut zwraca dane złożone. Na przykład: nazwa atrybutu to "apple" i zwraca on hash reprezentujący jego parametry, takie jak "weight", "color" itp. Klucz może wyglądać następująco:

jmx[com.example:Type=Hello,apple.weight]

W ten sposób nazwa atrybutu i klucz hash są rozdzielane przy użyciu symbolu kropki. Analogicznie, jeśli atrybut zwraca zagnieżdżone dane złożone, poszczególne części są rozdzielane kropką:

jmx[com.example:Type=Hello,fruits.apple.weight]

Atrybuty zwracające dane tabelaryczne

Atrybuty danych tabelarycznych składają się z jednego lub wielu atrybutów złożonych. Jeśli taki atrybut zostanie określony w parametrze nazwy atrybutu, wówczas wartość tej pozycji zwróci kompletną strukturę atrybutu w formacie JSON. Wartości poszczególnych elementów wewnątrz atrybutu danych tabelarycznych można pobrać za pomocą preprocessing.

Przykład atrybutu danych tabelarycznych:

 jmx[com.example:type=Hello,foodinfo]

Wartość pozycji:

[
  {
    "a": "apple",
    "b": "banana",
    "c": "cherry"
  },
  {
    "a": "potato",
    "b": "lettuce",
    "c": "onion"
  }
]

Problem z kropkami

Jak dotąd wszystko dobrze. Ale co, jeśli nazwa atrybutu lub klucz hash zawiera symbol kropki? Oto przykład:

jmx[com.example:Type=Hello,all.fruits.apple.weight]

To problem. Jak powiedzieć Zabbixowi, że nazwa atrybutu to „all.fruits”, a nie tylko „all”? Jak odróżnić kropkę, która jest częścią nazwy, od kropki, która oddziela nazwę atrybutu od kluczy hash?

Jest to możliwe, wystarczy poprzedzić kropki będące częścią nazwy ukośnikiem odwrotnym:

jmx[com.example:Type=Hello,all\.fruits.apple.weight]

W ten sam sposób, jeśli klucz hash zawiera kropkę, należy ją poprzedzić znakiem ucieczki:

jmx[com.example:Type=Hello,all\.fruits.apple.total\.weight]

Inne problemy

Znak ukośnika odwrotnego w nazwie atrybutu powinien być poprzedzony znakiem ucieczki:

jmx[com.example:type=Hello,c:\\documents]

Aby obsłużyć wszelkie inne znaki specjalne w kluczu pozycji JMX, zobacz sekcję dotyczącą formatu klucza pozycji section.

To właściwie wszystko. Życzymy udanego monitorowania JMX!

Nieprymitywne typy danych

Możliwa jest praca z niestandardowymi MBeanami zwracającymi nieprymitywne typy danych, które przesłaniają metodę toString().

Używanie niestandardowego endpointu z JBoss EAP 6.4

Niestandardowe endpointy umożliwiają pracę z różnymi protokołami transportowymi innymi niż domyślne RMI.

Aby zilustrować tę możliwość, spróbujmy skonfigurować monitorowanie JBoss EAP 6.4 jako przykład. Najpierw przyjmijmy kilka założeń:

• Masz już zainstalowany Zabbix Java gateway. Jeśli nie, możesz to zrobić zgodnie z dokumentacją.
• Zabbix serwer i Java gateway są zainstalowane z prefiksem /usr/local/
• JBoss jest już zainstalowany w /opt/jboss-eap-6.4/ i działa w trybie standalone
• Załóżmy, że wszystkie te komponenty działają na tym samym hoście
• Firewall i SELinux są wyłączone (lub odpowiednio skonfigurowane)

Wprowadźmy kilka prostych ustawień w pliku zabbix_server.conf:

JavaGateway=127.0.0.1
StartJavaPollers=5

A w pliku konfiguracyjnym zabbix_java/settings.sh (lub zabbix_java_gateway.conf):

START_POLLERS=5

Sprawdź, czy JBoss nasłuchuje na swoim standardowym porcie zarządzania:

$ netstat -natp | grep 9999
tcp        0      0 127.0.0.1:9999          0.0.0.0:*               LISTEN      10148/java

Teraz utwórzmy w Zabbix host z interfejsem JMX 127.0.0.1:9999.

Ponieważ wiemy, że ta wersja JBoss używa protokołu JBoss Remoting zamiast RMI, możemy odpowiednio zbiorczo zaktualizować parametr endpointu JMX dla pozycji w naszym szablonie JMX:

service:jmx:remoting-jmx://{HOST.CONN}:{HOST.PORT}

Zaktualizujmy pamięć podręczną konfiguracji:

/usr/local/sbin/zabbix_server -R config_cache_reload

Zwróć uwagę, że na początku możesz napotkać błąd.

„Unsupported protocol: remoting-jmx” oznacza, że Java gateway nie wie, jak pracować z określonym protokołem. Można to naprawić przez utworzenie pliku ~/needed_modules.txt z następującą zawartością:

jboss-as-remoting
jboss-logging
jboss-logmanager
jboss-marshalling
jboss-remoting
jboss-sasl
jcl-over-slf4j
jul-to-slf4j-stub
log4j-jboss-logmanager
remoting-jmx
slf4j-api
xnio-api
xnio-nio

a następnie wykonanie polecenia:

for i in $(cat ~/needed_modules.txt); do find /opt/jboss-eap-6.4 -iname "${i}*.jar" -exec cp '{}' /usr/local/sbin/zabbix_java/lib/ \; ; done

W ten sposób Java gateway będzie miał wszystkie niezbędne moduły do pracy z jmx-remoting. Pozostaje zrestartować Java gateway, chwilę odczekać i, jeśli wszystko zostało wykonane poprawnie, zobaczyć, że dane monitorowania JMX zaczną napływać do Zabbix (zobacz także: Latest data).