Java Application Monitoring Tool JMX (2)

Hold on, everybody. We’re about to start. But before we get behind the wheel, let’s do a routine recap of the points we shared last time.

Last time, because we could not stand the torture of the soul from the programmer’s heart, so we concentrated on training, and Java application monitoring tool JMX formally hit a face.

JMX, in my opinion, is like an old wine. Through this wine, we know the terms JCP and JSR in Java that you may not have known before. JConsole, a visual monitoring and management tool based on JMX built into the JDK, and the beautiful JVisualVM. At the same time, we got a taste of the not-so-great but functional jmxtools toolkit.

In one sentence: JMX smells good! If you haven’t felt her charm yet, it doesn’t matter, I believe you will fall in love with her through the recent sharing of several articles.

Do you still remember, the last period left a few questions, we will simply comb comb, may as well today to defeat each.

Legacy question 1: When we look at the source code, we will also find many XxMXBean definitions, so what is MXBean? What is the difference between mBeans and MXBeans?

Legacy question 2: We have neither defined the method to get memory, nor defined the method to get thread, etc., but where does the data displayed on JConsole and other management pages come from?

Ok, with questions in mind, let’s begin today’s sharing.

1.

In fact, although we have already made a face to face with JMX, but still should be dug further from the global architecture, a dig.

As shown in the figure above, JMX’s global architecture is divided into resource layer, agent layer, and adaptation layer from bottom to top. The resource layer mainly defines managed MBeans, that is, monitored applications. The proxy layer is primarily used to register and manage MBeans; The adaptation layer, also known as the connection layer, mainly implements various connection protocols, such as HTTP, RMI, and SNMP.

The remote management layer mainly refers to our monitoring and management application, understood as the client side.

Framework to understand a seven, seven, eight, understand a global overview, that might as well look back at the last period together with the code, combined with the code to a seat.

In fact, careful ape powder has already found that the code in the last period should be able to guess the name of the file.

1. The App class represents the resource (application) to be monitored, corresponding to the resource layer;

2. AppMBean interface, which represents what the agent layer can do to the application being monitored;

3. AppAgent class, known by name, corresponds to the agent layer;

4. Jmxtools, JConsole, and JVisualVM tools correspond to remote management applications.

It’s true. It’s kind of interesting.

2.

After all, there is no solution to our question: when we look at the framework source will find a lot of XxMXBean definition, that exactly what is MXBean? What is the difference between mBeans and MXBeans? Well, we might as well check out the official website.

The MXBean concept provides a simple way to code an MBean that only references a predefined set of types, the ones defined by javax.management.openmbean. In this way, you can be sure that your MBean will be usable by any client, including remote clients, without any requirement that the client have access to model-specific classes representing the types of your MBeans.

— Excerpted from official documents, for those interested, check out the link below.

https://docs.oracle.com/javase/8/docs/api/javax/management/MXBean.htmlCopy the code

In fact, the idea is to say,

1. Mxbeans provide an easy way to write MBeans that reference custom types;

2. With MXBeans, you can ensure that the MBean is used by any client without requiring the client to care about the classes that reference types in the MXBean.

But I guess you are still very confused ah, still very confused, that might as well give an example.

First of all, on the basis of the code shared in the previous period, our App application is equipped with a Watchdog.

Then add the managed App to the Watchdog.

The operation methods are then exposed in the AppMBean interface.

Then create a watchdog on the agent layer AppAgent and add it to the App.

Code seconds masturbation, run to have a look, everything is ready, please out of the application management tool JConsole to play, god la masturbation! Find the value of watchdog is not available? !

This is not a Bug, but keep this effect of mBeans in mind, because it will soon be lost. Next, change the AppMBean to AppMXBean.

Then replace the interface implemented by App with AppMXBean as well.

The code changes in a split second, so you still need to run and look at it, and everything is ready again, and then go out and play with JConsole.

Unexpectedly watchdog has value, and it is javax.management.openmbean.Com positeDataSupport, day lulu, what is this? Click and see if there’s any surprise.

Sure enough, point the moment clear, the original is the value of the watchdog, fierce fierce.

Okay, the demo is almost over, so do you get it? In fact, MXBeans are more than MBeans (X), support custom reference type data display.

3.

There is no definition of how to get memory, nor thread, etc., but where does the data displayed on the monitor page come from? That might as well scratch a scratch JDK API, we have a prescription to the disease.

Let’s take a look at the JDK 5 API and see that there are a number of built-in MXBean definitions in the java.lang.management package.

https://docs.oracle.com/javase/1.5.0/docs/api/index.html?java/lang/management/package-summary.htmlCopy the code

https://docs.oracle.com/javase/8/docs/api/index.html?java/lang/management/package-summary.htmlCopy the code

At this stage, we are confused and confused, so we should be a little clearer. But sometimes when we study, we still need to break the casserole and ask exactly what these are for. Let’s take the common MXBean definitions in JDK 5 and JDK 8 and draw a brain map to explain them thoroughly, because some of them do come into play.

I believe that through the above manual, and then in-depth middleware or open source framework worth mentioning, will certainly meet ghost kill ghost, smooth sailing.

4.

Soul torture: Dynamic modification of application parameters, can you change?

It’s time to formally face the soul torture of the procedural ape once again. What’s the solution to this soul torture?

Let me talk about the solution: is it feasible to put the parameters that need to be configured in an MBean, and then provide a management configuration page for convenience? Let’s write some code to see if it works.

Start by defining a parameter configuration interface, ConfigMXBean.

The managed object Config is then defined and the ConfigMXBean interface is implemented.

Next, the agent layer ConfigAgent is written and jMXTools is used to provide page management.

Once the code is written, run around and visit http://localhost:8888/.

When we select True and hit Apply, the console outputs true. Wow!!!! It’s amazing. You can test it.

Let’s share a simple implementation idea of dynamically changing parameters without restarting an application. Imagine what this can do, such as switching between old and new functions and dynamically changing risk rating levels using JMX.

5.

To be honest, why am I sharing this technology? Druid uses JMX to monitor its own database connection pool. For example Resin, Tomcat, Weblogic and so on, all provide JMX service in the birth, so it is necessary to comb through and share with you, in case you can also use it (covering your mouth to laugh).

Well, today’s car to the station, there are a lot of application scenarios did not say, we still listen to the next decomposition, really hope an ape small talk each share can help you a little bit, finally I wish you in the days to come, Dapeng spread its wings with the wind, soaring to heaven and earth.

Please follow the wechat public account “One Ape Little Talk” for more wonderful sharing.

Recommended reading:

Java Application Monitoring Tool JMX (1)

Life depends on reflection, Java depends on generics

The art of making eye contact