qual è la differenza tra jolokia e jmxtrans? Quando scegliere l'uno rispetto all'altro?

Question

Sto cercando uno strumento di interrogazione JMX. Mi sono imbattuto in jolokia & jmxtrans, entrambi supportano l'interrogazione basata su JSON. JMXtrans ha scrittori di strumenti di monitoraggio che penso manchi in Jolokia. Ho cercato su Google, ma non ho ricevuto molte informazioni a confronto dei due. Ma ho letto post di blog positivi su entrambi gli strumenti. Se qualcuno li ha usati prima, pls condividi le tue esperienze ...

Answer 1

Sono l'autore di jmxtrans. Ho considerato Jolokia prima di sviluppare jmxtrans. Ho scelto di sviluppare con jmxtrans perché avevo in mente un altro caso d'uso.

Jolokia corre come una guerra in Tomcat. È simile a jmxtrans in quanto ti permette di interrogare un server JMX, ma è su dove finisce la somiglianza. Dovresti implementare il resto di jmxtrans su Jolokia per avere parità di funzionalità.

D'altra parte, jmxtrans è autonomo senza requisiti su Tomcat. Il mio target di riferimento è il ruolo di netops/devops. È configurato con una struttura basata su JSON relativamente semplice, quindi non richiede un livello di ingegneria per configurarlo e utilizzarlo.

Il pensiero è che si utilizza jmxtrans per monitorare continuamente i servizi che espongono le statistiche tramite jmx. Usa jmxtrans per 'trasformare' i dati da jmx in qualunque formato di output tu voglia. Generalmente, le persone con la deviazione vogliono integrare le proprie JVM con una sorta di soluzione di monitoraggio come Graphite/Ganglia, quindi ho fornito agli scrittori di output quegli strumenti.

jmxtrans è anche molto intelligente su come esegue query sui server jmx e c'è un po 'di ottimizzazione in questo. C'è anche molto lavoro per permetterti di fare cose come parallelizzare le richieste a molti server per abilitare la scalabilità di jmxtrans per interrogare continuamente centinaia di server con una singola istanza di jmxtrans.

Spero che chiarisca un po 'le cose. Se hai domande specifiche, sono felice di rispondergli.

Answer 2

Infatti, jmxtrans e Jolokia hanno un focus diverso. Jmxtrans è una soluzione di monitoraggio completa con uno scheduler che interroga periodicamente la richiesta JMX e invia i risultati a un backend come grafite o rrdtool. Esso utilizza comunicazione standard JSR-160 (basato su RMI) per l'interrogazione JMX enabeled server Java

Jolokia d'altra parte è un adattatore HTTP/JSON-JMX, che permette un facile accesso per i client non-Java e aggiunge alcune caratteristiche uniche che non sono disponibili per un'implementazione pura JSR-160. Per l'integrazione in una piattaforma di monitoraggio è necessario un altro software. Per Nagios, c'è il numero Jmx4Perl che fornisce un plugin Nagios completo per interrogare gli agenti Jolokia.

Dal momento che sono l'autore Jolokia, mi permetta di permetto di sottolineare alcuni punti salienti di Jolokia

• Molte richieste possono essere inviati in una sola volta come singolo richieste di massa. Ciò consente di interrogare centinaia di attributi con un singolo giro di HTTP. Questo fa davvero una grande differenza in ambienti di grandi dimensioni.
• causa l'uso di HTTP Jolokia consente una facile interrogazione attraverso i confini del firewall (che è un incubo quando si utilizzano connettori JMX standard)
• Belle autorizzazione grana è facilmente possibile utilizzando un file di criteri XML pianura
• agenti sono a disposizione non solo per Tomcat o qualsiasi altro contenitore Java EE ma anche per qualsiasi applicazione Java 6 (ad esActiveMQ o Camel)
• Una bella suite di strumenti da riga di comando (ad esempio una shell JMX basata sulla lettura con il completamento del comando sensibile al contesto) viene fornita con Jmx4Perl.
• Sono disponibili librerie di accesso da Perl, Javascript, Python, ....
• .... Per maggiori informazioni, si rimanda alla www.jolokia.org

In sintesi, penso che si dovrebbe utilizzare jmxtrans quando avete bisogno di una soluzione completa di monitoraggio sulla base di JSR-160 servizi remoti (tuttavia, è possibile utilizzare Nagios e check_jmx4perl, anche) e Jolokia quando è necessario superare le limitazioni JSR-160 o possono beneficiare di una delle sue caratteristiche uniche. Si potrebbe anche immaginare di integrare Jolokia in jmxtrans per la comunicazione ai server da monitorare, che poi andrebbero su JSON/HTTP invece di JSR-160 RMI (forse questo chiarisce anche la differenza di attenzione e il caso d'uso supportato).

Answer 3

mi permetta di mettere più un progetto sul tavolo - https://github.com/dimovelev/metrics-sampler interroga i dati JMX utilizzando espressioni regolari e sostituzione di variabile e supporta anche le query JDBC come fonti metrici (per lo più per monitorare le nostre statistiche Oracle DB) e mod_qos per la roba mod_qos apache . Abbiamo solo bisogno di grafite come output e questo è l'unico output che attualmente supporta.

A proposito, IMHO le porte JMX sono problematiche con i firewall solo perché l'hotspot preleva una porta temporanea casuale all'avvio. Con jrockit può essere specificato (sulla stessa porta del registro) con un'opzione jvm standard. Per fare ciò sull'hotspot devi codificarlo tu stesso (o riutilizzare il codice ad es. Dal connettore jmx di tomcat). La parte bella è che va bene impostare entrambe le porte sullo stesso valore, quindi con una sola regola del firewall.

Acclamazioni Dimo ​​