I would re-iterate Prometheus, it allows for node_collector that also gives you OS metrics, + the JMX integration that tells you how the Java servers are doing + the topic depth modules.
All going into prometheus, all visualised nicely as one pane of glass via Grafana. and well if you doing coding, prometheus is really easy to use, and if you have any Kubernetes environments, it's the defacto instrumentation standard, actually now come as part of the Openshift deployment. G On Thu, Mar 19, 2020 at 1:02 PM Sachin Mittal <sjmit...@gmail.com> wrote: > How about jmxterm. > https://cwiki.apache.org/confluence/display/KAFKA/jmxterm+quickstart > I have found this very helpful. > > > On Thu, Mar 19, 2020 at 3:51 PM Gioacchino Vino <gioacchinov...@gmail.com> > wrote: > > > Hi, > > > > > > I would like to share my experience with you. > > > > Even if I found out that prometheus is the a simple and fast solution, > > since I'm using InfluxDB (and Telegraf) in my project, I'm using the > chain: > > > > Jolokia -> Telegraf -> InfluxDB -> Grafana > > > > > > Some useful links: > > > > https://jolokia.org/ > > > > > https://github.com/influxdata/telegraf/tree/master/plugins/inputs/jolokia2 > > > > > > Someone had experience in both approaches? > > > > > > Cheeers, > > > > Gioacchino > > > > > > > > On 19/03/20 07:49, 张祥 wrote: > > > Hi, > > > > > > I want to know what the best practice to collect Kafka JMX metrics is. > I > > > haven't found a decent way to collect and parse JMX in Java (because it > > is > > > too much) and I learn that there are tools like tools like jmxtrans to > do > > > this. I wonder if there is more. Thanks. Regards. > > > > > > -- You have the obligation to inform one honestly of the risk, and as a person you are committed to educate yourself to the total risk in any activity! Once informed & totally aware of the risk, every fool has the right to kill or injure themselves as they see fit!
