JMX-monitoring kan worden gebruikt om JMX-tellers van een Java-toepassing te monitoren.
JMX-monitoring heeft native ondersteuning in Zabbix in de vorm van een Zabbix-daemon genaamd "Zabbix Java gateway", geïntroduceerd sinds Zabbix 2.0.
Om de waarde van een specifieke JMX-teller op een host op te halen, vraagt de Zabbix-server de Zabbix Java gateway om informatie op te halen. De Java gateway gebruikt op zijn beurt de JMX-beheer-API om op afstand de gewenste toepassing te bevragen.
Voor meer details en installatie-instructies zie het gedeelte Zabbix Java gateway.
De communicatie tussen de Java gateway en de gemonitorde JMX-toepassing mag niet geblokkeerd zijn door een firewall.
Een Java-toepassing heeft geen extra software nodig om te worden geïnstalleerd, maar moet worden gestart met de onderstaande opdrachtopties om ondersteuning te bieden voor externe JMX-bewaking.
Als absoluut minimum, als je gewoon wilt beginnen met het bewaken van een eenvoudige Java-toepassing op een lokale host zonder beveiliging, start je deze met deze opties:
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 /usr/share/doc/openjdk-6-jre-headless/demo/jfc/Notepad/Notepad.jar
Hiermee laat je Java luisteren naar inkomende JMX-verbindingen op poort 12345, alleen vanaf de lokale host, en je geeft aan dat authenticatie of SSL niet vereist is.
Als je verbindingen op een ander netwerkinterface wilt toestaan, stel dan de parameter -Djava.rmi.server.hostname in op het IP-adres van die interface.
Als je strenger wilt zijn op het gebied van beveiliging, zijn er veel andere Java-opties beschikbaar. Bijvoorbeeld, het volgende voorbeeld start de toepassing met een veelzijdigere set opties en opent het voor een breder netwerk, niet alleen de lokale host.
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 /usr/share/doc/openjdk-6-jre-headless/demo/jfc/Notepad/Notepad.jar
De meeste (zo niet alle) van deze instellingen kunnen worden gespecificeerd in /etc/java-6-openjdk/management/management.properties
(of waar dat bestand zich op jouw systeem bevindt).
Merk op dat als je SSL wilt gebruiken, je het startup.sh
-script moet aanpassen door de -Djavax.net.ssl.*
-opties toe te voegen aan de Java-gateway, zodat deze weet waar de sleutel- en vertrouwensopslagbestanden zich bevinden.
Zie Monitoring and Management Using JMX voor een gedetailleerde beschrijving.
Met Java gateway actief, waarbij de server weet waar deze te vinden is, en een Java-toepassing gestart met ondersteuning voor externe JMX-monitoring, is het tijd om de interfaces en items in de Zabbix GUI te configureren.
Je begint door een JMX-type interface aan te maken op de host van interesse.
Alle verplichte invoervelden zijn gemarkeerd met een rode asterisk.
Voor elke JMX-teller waarin je geïnteresseerd bent, voeg je een JMX-agent-item toe dat aan die interface is gekoppeld.
De sleutel in de onderstaande schermafbeelding zegt jmx["java.lang:type=Memory","HeapMemoryUsage.used"]
.
Alle verplichte invoervelden zijn gemarkeerd met een rode asterisk.
De velden die specifieke informatie vereisen voor JMX-items zijn:
Type | Stel hier JMX-agent in. |
Sleutel | De jmx[] item sleutel bevat drie parameters:objectnaam - de objectnaam van een MBean attribuutnaam - een MBean-attribuutnaam met optionele samengestelde gegevensveldnamen gescheiden door punten unieke korte beschrijving - een unieke beschrijving die meerdere JMX-items met dezelfde objectnaam en attribuutnaam op de host mogelijk maakt (optioneel) Zie hieronder voor meer details over JMX-item sleutels. Sinds Zabbix 3.4 kun je MBeans en MBean-attributen ontdekken met behulp van een jmx.discovery[] low-level discovery item. |
JMX-eindpunt | Je kunt een aangepast JMX-eindpunt specificeren. Zorg ervoor dat de verbindingsparameters van het JMX-eindpunt overeenkomen met de JMX-interface. Dit kan worden bereikt door {HOST.*} macro's te gebruiken, zoals in het standaard JMX-eindpunt wordt gedaan. Dit veld wordt ondersteund sinds 3.4.0. {HOST.*} macro's en gebruikersmacro's worden ondersteund. |
Gebruikersnaam | Geef de gebruikersnaam op als je authenticatie hebt geconfigureerd voor je Java-toepassing. Gebruikersmacro's worden ondersteund. |
Wachtwoord | Geef het wachtwoord op als je authenticatie hebt geconfigureerd voor je Java-toepassing. Gebruikersmacro's worden ondersteund. |
Als je een Booleaanse teller wilt bewaken die ofwel "true" of "false" is, specificeer je het type informatie als "Numeriek (ongesigneerd)" en selecteer je de "Boolean to decimal" voorverwerkingsstap in het tabblad Voorverwerking. De server zal Booleaanse waarden respectievelijk als 1 of 0 opslaan.
Een MBean-objectnaam is niets meer dan een tekenreeks die je definieert in je Java-toepassing. Een attribuutnaam kan daarentegen wat complexer zijn. In het geval dat een attribuut een primitief gegevenstype retourneert (een geheel getal, een tekenreeks, enzovoort), hoef je je geen zorgen te maken, de sleutel zal er zo uitzien:
In dit voorbeeld is de objectnaam "com.example:Type=Hello", de attribuutnaam is "weight", en het type van het geretourneerde waarde zou waarschijnlijk "Numeriek (float)" moeten zijn.
Het wordt ingewikkelder wanneer je attribuut samengestelde gegevens retourneert. Bijvoorbeeld: je attribuutnaam is "apple" en het retourneert een hash die zijn parameters vertegenwoordigt, zoals "weight", "color", enzovoort. Je sleutel kan er zo uitzien:
Dit is hoe een attribuutnaam en een hash-sleutel van elkaar worden gescheiden, door gebruik te maken van een puntteken. Op dezelfde manier, als een attribuut geneste samengestelde gegevens retourneert, worden de delen gescheiden door een punt:
Attributen die tabulaire gegevens retourneren bestaan uit één of meerdere samengestelde attributen. Als een dergelijk attribuut wordt gespecificeerd in de attribuutnaam parameter, dan zal de waarde van dit item de volledige structuur van het attribuut retourneren in JSON-indeling. De individuele elementwaarden binnen het attribuut met tabulaire gegevens kunnen worden opgehaald met behulp van voorbewerking.
Voorbeeld van een attribuut met tabulaire gegevens:
Waarde van het item:
Tot nu toe gaat het goed. Maar wat als een attribuutnaam of een hash-sleutel het punt symbool bevat? Hier is een voorbeeld:
Dat is een probleem. Hoe vertel je Zabbix dat de attribuutnaam "all.fruits" is en niet alleen "all"? Hoe onderscheid je een punt dat deel uitmaakt van de naam van een punt dat een attribuutnaam en hash-sleutels scheidt?
Vóór 2.0.4 kon Zabbix Java Gateway dergelijke situaties niet verwerken en bleven gebruikers zitten met NIET-ONDERSTEUNDE items. Sinds 2.0.4 is dit mogelijk, het enige wat je hoeft te doen is de punten die deel uitmaken van de naam te ontsnappen met een backslash:
Op dezelfde manier, als je hash-sleutel een punt bevat, ontsnap je eraan:
Een backslash-teken in een attribuutnaam moet worden ontsnapt:
Voor het omgaan met andere speciale tekens in de JMX-item sleutel, zie de sectie item sleutel formaat.
Dit is eigenlijk alles wat er is. Veel succes met JMX-monitoring!
Sinds Zabbix 4.0.0 is het mogelijk om te werken met aangepaste MBeans die niet-primitieve gegevenstypen retourneren en de toString()-methode overschrijven.
Aangepaste eindpunten maken het werken met verschillende transportprotocollen mogelijk dan de standaard RMI.
Om deze mogelijkheid te illustreren, gaan we JBoss EAP 6.4-monitoring configureren als voorbeeld. Laten we eerst een aantal aannames doen:
/usr/local/
./opt/jboss-eap-6.4/
en draait in de standalone modus.Laten we enkele eenvoudige instellingen maken in zabbix_server.conf
:
JavaGateway=127.0.0.1
StartJavaPollers=5
En in het configuratiebestand zabbix_java/settings.sh
(of zabbix_java_gateway.conf
):
START_POLLERS=5
Controleer of JBoss luistert naar zijn standaard beheerpoort:
Laten we nu een host maken met JMX-interface 127.0.0.1:9999 in Zabbix.
Aangezien we weten dat deze versie van JBoss het JBoss Remoting-protocol in plaats van RMI gebruikt, kunnen we de JMX-eindpunt parameter voor items in ons JMX-template massaal bijwerken:
service:jmx:remoting-jmx://{HOST.CONN}:{HOST.PORT}
Laten we de configuratiecache bijwerken:
Houd er rekening mee dat je mogelijk eerst een fout tegenkomt.
"Unsupported protocol: remoting-jmx" betekent dat de Java Gateway niet weet hoe te werken met het gespecificeerde protocol. Dit kan worden opgelost door een ~/needed_modules.txt
bestand aan te maken met de volgende inhoud:
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
en vervolgens het volgende commando uit te voeren:
$ 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
Hierdoor heeft de Java Gateway alle benodigde modules om te werken met jmx-remoting. Het enige dat nog resteert is het herstarten van de Java Gateway, even wachten en als je alles goed hebt gedaan, zou je zien dat JMX-monitoringsgegevens in Zabbix beginnen aan te komen (zie ook: Laatste gegevens).