有人曾经使用过远程 JMX JConsole 吗？
看来我过去从来没有让这个工作过。 目前，我知道它不起作用。
但是我们启动我们的Java进程：
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=6002
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
我可以telnet到端口，并且“有东西在那里”（也就是说，如果我不启动该进程，则没有任何答案，但如果我启动，它就会出现），但我不能让 JConsole 开始填写 IP 和端口。
看起来应该是这么简单，但是没有错误，没有噪音，什么也没有。 就是行不通。
有人知道这方面的热门提示吗？
It seems that I've never got this to work in the past. Currently, I KNOW it doesn't work.
But we start up our Java process:
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=6002
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
I can telnet to the port, and "something is there" (that is, if I don't start the process, nothing answers, but if I do, it does), but I can not get JConsole to work filling in the IP and port.
Seems like it should be so simple, but no errors, no noise, no nothing. Just doesn't work.
Anyone know the hot tip for this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（20）
当测试/调试/诊断远程 JMX 问题时，首先始终尝试连接包含 MBeanServer 的同一主机（即本地主机），以排除网络和其他非 JMX 特定问题。
When testing/debugging/diagnosing remote JMX problems, first always try to connect on the same host that contains the MBeanServer (i.e. localhost), to rule out network and other non-JMX specific problems.
这里已经有一些很好的答案，但是，有一个稍微简单的方法，我认为值得分享。
sushicutta 的方法很好，但是非常手动，因为您每次都必须获取 RMI 端口。 值得庆幸的是，我们可以通过使用 SOCKS 代理来解决这个问题，而不是显式打开端口隧道。 这种方法的缺点是您在计算机上运行的 JMX 应用程序需要能够配置为使用代理。 大多数进程都可以通过添加 java 属性来完成此操作，但是，某些应用程序不支持此操作。
步骤：
将 JMX 选项添加到远程 Java 服务的启动脚本中：
<前><代码>-Dcom.sun.management.jmxremote=true
-Dcom.sun.management.jmxremote.port=8090
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
设置到远程计算机的 SOCKS 代理连接：
配置本地 Java 监控应用程序以使用 SOCKS 代理 (localhost:9696)。 注意：您有时可以从命令行执行此操作，即：
There are already some great answers here, but, there is a slightly simpler approach that I think it is worth sharing.
sushicutta's approach is good, but is very manual as you have to get the RMI Port every time. Thankfully, we can work around that by using a SOCKS proxy rather than explicitly opening the port tunnels. The downside of this approach is JMX app you run on your machine needs to be able to be configured to use a Proxy. Most processes you can do this from adding java properties, but, some apps don't support this.
Steps:
Add the JMX options to the startup script for your remote Java service:
Set up a SOCKS proxy connection to your remote machine:
Configure your local Java monitoring app to use the SOCKS proxy (localhost:9696). Note: You can sometimes do this from the command line, i.e.:
以下内容对我有用（尽管我认为端口 2101 并没有真正对此做出贡献）：
我正在从远程计算机连接到运行 Docker 的服务器，并且该进程位于容器内。 另外，我停止了firewallD，但我不认为这是问题所在，因为即使防火墙打开，我也可以远程登录到2100。
希望能帮助到你。
The following worked for me (though I think port 2101 did not really contribute to this):
I am connecting from a remote machine to a server which has Docker running and the process is inside the container. Also, I stopped firewallD but I don't think that was the issue as I could telnet to 2100 even with the firewall open.
Hope it helps.
我在 Windows 上运行 JConsole/JVisualVm，挂钩到运行 Linux Redhat ES3 的 tomcat。
使用以下命令禁用数据包过滤对我来说很有效：
其中 jconsole-host 是运行 JConsole 的主机名或主机地址，jmxremote-port 是为 com.sun.management.jmxremote.port 设置的端口号远程管理。
I am running JConsole/JVisualVm on windows hooking to tomcat running Linux Redhat ES3.
Disabling packet filtering using the following command did the trick for me:
where jconsole-host is either the hostname or the host address on which JConsole runs on and jmxremote-port is the port number set for com.sun.management.jmxremote.port for remote management.
我正在使用 boot2docker 运行带有 Tomcat 的 docker 容器，并且遇到了同样的问题，解决方案是：
-Djava.rmi.server.hostname=192.168.59.103docker run ... -p 9999:9999 ...。 使用不同的端口不起作用。I'm using boot2docker to run docker containers with Tomcat inside and I've got the same problem, the solution was to:
-Djava.rmi.server.hostname=192.168.59.103docker run ... -p 9999:9999 .... Using different ports does not work.您还需要确保您的机器名称解析为 JMX 绑定到的 IP； 不是本地主机，也不是 127.0.0.1。 对我来说，将一个条目放入主机中明确定义这一点很有帮助。
You need to also make sure that your machine name resolves to the IP that JMX is binding to; NOT localhost nor 127.0.0.1. For me, it has helped to put an entry into hosts that explicitly defines this.
让 JMX 通过防火墙一点也不难。 有一个小问题。 您必须转发 JMX 配置的端口，即。 9010 及其在我的机器上侦听的动态端口之一> 30000
Getting JMX through the firewall isn't that hard at all. There is one small catch. You have to forward both your JMX configured port ie. 9010 and one of dynamic ports its listens to on my machine it was > 30000
这些是对我有用的步骤（服务器端防火墙后面的 debian，从我的本地 Mac 通过 VPN 到达）：
检查服务器 ip
使用 JVM 参数：
运行应用程序
查找正在运行的 java 进程的 pid
检查 JMX/RMI 使用的所有端口
打开防火墙上第 5 步中的所有端口
瞧。
These are the steps that worked for me (debian behind firewall on the server side, reached over VPN from my local Mac):
check server ip
use JVM params:
run application
find pid of the running java process
check all ports used by JMX/RMI
open all ports from step 5 on the firewall
Voila.
我正在尝试 JMC 运行飞行记录器（JFR）来分析远程服务器上的 NiFi，该服务器不提供运行 JMC 的图形环境。
根据此处给出的其他答案，并经过多次尝试和错误，以下是我在启动 NiFi 时向 JVM 提供的内容（conf/bootstrap.conf）：
我确实将其放入 < em>/etc/hosts，尽管我怀疑它是否需要：
然后，在启动 JMC 时，我使用这些属性创建远程连接：
顺便说一句，如果我单击自定义 JMX 服务 URL，我会看到：
这终于做到了为我。
I'm trying to JMC to run the Flight Recorder (JFR) to profile NiFi on a remote server that doesn't offer a graphical environment on which to run JMC.
Based on the other answers given here, and upon much trial and error, here is what I'm supplying to the JVM (conf/bootstrap.conf)when I launch NiFi:
I did put this in /etc/hosts, though I doubt it's needed:
Then, upon launching JMC, I create a remote connection with these properties:
Incidentally, if I click the Custom JMX service URL, I see:
This finally did it for me.
为了做出贡献，这就是我在 CentOS 6.4 for Tomcat 6 上所做的。
关闭 iptables 服务
将以下行添加到tomcat6.conf
这样我就可以使用 JConsole 从另一台 PC 进行连接。
In order to make a contribution, this is what I did on CentOS 6.4 for Tomcat 6.
Shutdown iptables service
Add the following line to tomcat6.conf
This way I was able to connect from another PC using JConsole.
我有一个解决方案：
如果您的 Java 进程在防火墙后面的 Linux 上运行，并且您想在本地 Windows 上启动 JConsole / Java VisualVM / Java Mission Control机将其连接到Java 进程的 JMX 端口。
您需要通过 SSH 登录访问您的 Linux 机器。 所有通信都将通过 SSH 连接进行隧道传输。
提示：无论是否有防火墙，此解决方案都有效。
缺点：每次重新启动 java 进程时，您都需要再次执行 4 - 9 中的所有步骤。
1. 您需要从此处获取适合您的 Windows 计算机的 putty 套件：
2. 在您的 linux 机器上定义一个空闲端口：
示例：
3. 添加参数到 java 进程linux机器
这必须完全像这样完成。 如果按照下面的方式完成，它适用于防火墙后面的 Linux 机器（它的工作原理是
-Djava.rmi.server.hostname=localhost参数）。示例：
4. 获取 Java 进程的进程 ID
示例：
5. 查找 RMIServer 存根下载的任意端口
java 进程在 linux 计算机上打开一个新的 TCP 端口，RMI 服务器存根将在其中可供下载。 该端口还需要通过 SSH 隧道可用才能连接到 Java 虚拟机。
使用
netstat -lp可以找到这个端口，lsof -i也可以提示java进程打开了哪个端口。注意：当 java 进程启动时，此端口始终会更改。
示例：
6. 使用 putty 从 Windows 计算机启用两个 SSH 隧道
示例：
7. 使用启用了此 SSH 隧道的 Putty 登录 Linux 计算机。
让 putty 会话保持打开状态。
当您登录时，Putty 会通过 SSH 端口 22 将所有 TCP 连接通过隧道传输到 Linux 计算机。
JMX 端口：
RMIServer-Stub-Port：
8启动 JConsole / Java VisualVM / Java Mission Control 使用以下 URL 连接到您的 Java 进程
这有效，因为 JConsole / Java VisualVM / Java Mission Control 认为您连接到本地 Windows 计算机上的端口。 但是 Putty 将所有有效负载发送到端口 15666 到您的 Linux 机器。
在 Linux 机器上，java 进程首先给出应答并发回 RMIServer 端口。 在此示例中为 37123。
然后 JConsole / Java VisualVM / Java Mission Control 认为它连接到 localhost:37123 并且 putty 会将整个有效负载转发到 linux 机器
java 进程应答并且连接打开。
示例：
9. 享受 #8-]
I have a solution for this:
If your Java process is running on Linux behind a firewall and you want to start JConsole / Java VisualVM / Java Mission Control on Windows on your local machine to connect it to the JMX Port of your Java process.
You need access to your linux machine via SSH login. All Communication will be tunneled over the SSH connection.
TIP: This Solution works no matter if there is a firewall or not.
Disadvantage: Everytime you restart your java process, you will need to do all steps from 4 - 9 again.
1. You need the putty-suite for your Windows machine from here:
2. Define one free Port on your linux machine:
Example:
3. Add arguments to java process on the linux machine
This must be done exactly like this. If its done like below, it works for linux Machines behind firewalls (It works cause of the
-Djava.rmi.server.hostname=localhostargument).Example:
4. Get Process-Id of your Java Process
Example:
5. Find arbitrary Port for RMIServer stubs download
The java process opens a new TCP Port on the linux machine, where the RMI Server-Stubs will be available for download. This port also needs to be available via SSH Tunnel to get a connection to the Java Virtual Machine.
With
netstat -lpthis port can be found also thelsof -igives hints what port has been opened form the java process.NOTE: This port always changes when java process is started.
Example:
6. Enable two SSH-Tunnels from your Windows machine with putty
Example:
7. Login to your Linux machine with Putty with this SSH-Tunnel enabled.
Leave the putty session open.
When you are logged in, Putty will tunnel all TCP-Connections to the linux machine over the SSH port 22.
JMX-Port:
RMIServer-Stub-Port:
8. Start JConsole / Java VisualVM / Java Mission Control to connect to your Java Process using the following URL
This works, cause JConsole / Java VisualVM / Java Mission Control thinks you connect to a Port on your local Windows machine. but Putty send all payload to the port 15666 to your linux machine.
On the linux machine first the java process gives answer and send back the RMIServer Port. In this example 37123.
Then JConsole / Java VisualVM / Java Mission Control thinks it connects to localhost:37123 and putty will send the whole payload forward to the linux machine
The java Process answers and the connection is open.
Example:
9. ENJOY #8-]
让 JMX 通过防火墙确实很困难。 问题是标准 RMI 使用第二个随机分配的端口（除了 RMI 注册表之外）。
我们有三种可行的解决方案，但每种情况都需要不同的解决方案：
带有 Socks 代理的 SSH 隧道上的 JMX，使用带有 SSH magic 的标准 RMI
http://simplygenius.com/2010/08/jconsole-via -socks-ssh-tunnel.html
JMX MP（标准 RMI 的替代方案），仅使用一个固定端口，但在服务器和客户端上需要一个特殊的 jar
http://meteatamel.wordpress.com/2012/02/ 13/jmx-rmi-vs-jmxmp/
启动JMX Server表单代码，在那里可以使用标准RMI并使用固定的第二个端口：
https://issues.apache.org/bugzilla/show_bug.cgi?id=39055
Getting JMX through the Firewall is really hard. The Problem is that standard RMI uses a second random assigned port (beside the RMI registry).
We have three solution that work, but every case needs a different one:
JMX over SSH Tunnel with Socks proxy, uses standard RMI with SSH magic
http://simplygenius.com/2010/08/jconsole-via-socks-ssh-tunnel.html
JMX MP (alternative to standard RMI), uses only one fixed port, but needs a special jar on server and client
http://meteatamel.wordpress.com/2012/02/13/jmx-rmi-vs-jmxmp/
Start JMX Server form code, there it is possible to use standard RMI and use a fixed second port:
https://issues.apache.org/bugzilla/show_bug.cgi?id=39055
您可能遇到了防火墙问题。 “问题”是您指定的端口不是唯一使用的端口，它使用 1 个甚至 2 个以上的 RMI 端口，而这些端口可能被防火墙阻止。
如果您使用默认的 RMI 配置，则不会预先知道其中一个额外的端口，因此您必须开放大量端口 - 这可能不会让服务器管理员感到高兴。
有一个不需要打开大量端口的解决方案，但是，我已经使用来自
http://forums.sun.com/thread.jspa?threadID= 的组合源代码片段和提示来使其工作。 5267091- 链接不再有效http://blogs.oracle.com/ jmxetc/entry/connecting_through_firewall_using_jmx - 链接不再有效，请参阅回程机
http://java.sun.com/javase/6/docs/technotes/guides/management/agent.html
甚至可以设置 ssh 隧道并仍然让它工作:-)
You are probably experiencing an issue with a firewall. The 'problem' is that the port you specify is not the only port used, it uses 1 or maybe even 2 more ports for RMI, and those are probably blocked by a firewall.
One of the extra ports will not be know up front if you use the default RMI configuration, so you have to open up a big range of ports - which might not amuse the server administrator.
There is a solution that does not require opening up a lot of ports however, I've gotten it to work using the combined source snippets and tips from
http://forums.sun.com/thread.jspa?threadID=5267091- link doesn't work anymorehttp://blogs.oracle.com/jmxetc/entry/connecting_through_firewall_using_jmx - link doesn't work anymore, see Wayback Machine
http://java.sun.com/javase/6/docs/technotes/guides/management/agent.html
It's even possible to setup an ssh tunnel and still get it to work :-)
检查您的服务器是否位于防火墙后面。 JMX是基于RMI的，它在启动时打开两个端口。 一是注册端口，默认为1099，可以通过
com.sun.management.jmxremote.port选项指定。 另一种是用于数据通信的，并且是随机的，这就是导致问题的原因。 好消息是，从 JDK6 开始，可以通过 com.sun.management.jmxremote.rmi.port 选项指定此随机端口。Check if your server is behind the firewall. JMX is base on RMI, which open two port when it start. One is the register port, default is 1099, and can be specified by the
com.sun.management.jmxremote.portoption. The other is for data communication, and is random, which is what cause problem. A good news is that, from JDK6, this random port can be specified by thecom.sun.management.jmxremote.rmi.portoption.提示：
RMI 端口在任意端口号处打开。 如果您有防火墙并且不想打开端口 1024-65535（或使用 VPN），那么您需要执行以下操作。
您需要修复（如具有已知编号）RMI 注册表和 JMX/RMI 服务器端口。 您可以通过在 lib-dir 中放置一个 jar 文件（catalina-jmx-remote.jar 它在 extra 中）并在服务器下配置一个特殊的侦听器来完成此操作：（
当然还有用于激活 JMX 的常用标志，
请参阅：JMX Remote Lifecycle Listener在 http://tomcat.apache.org/tomcat-6.0-doc/ config/listeners.html
然后你可以使用这个可怕的 URL 进行连接：
PROTIP:
The RMI port are opened at arbitrary portnr's. If you have a firewall and don't want to open ports 1024-65535 (or use vpn) then you need to do the following.
You need to fix (as in having a known number) the RMI Registry and JMX/RMI Server ports. You do this by putting a jar-file (catalina-jmx-remote.jar it's in the extra's) in the lib-dir and configuring a special listener under server:
(And ofcourse the usual flags for activating JMX
See: JMX Remote Lifecycle Listener at http://tomcat.apache.org/tomcat-6.0-doc/config/listeners.html
Then you can connect using this horrific URL:
可以通过将以下行添加到步骤 3 来跳过 Sushicutta 的步骤 4-7：
例如
添加到启动参数：
对于端口转发，请使用以下方式连接：
如果您的主机是垫脚石，只需在上述垫脚石上运行以下命令即可链接端口转发：
请注意 hostname=localhost来确保jmxremote告诉rmi连接使用隧道。 否则，它可能会尝试直接连接并击中防火墙。
Sushicutta's steps 4-7 can be skipped by adding the following line to step 3:
e.g.
Add to start up parameters:
For the port forwarding, connect using:
if your host is a stepping stone, simply chain the port forward by running the following on the step stone after the above:
Mind that the hostname=localhost is needed to make sure the jmxremote is telling the rmi connection to use the tunnel. Otherwise it might try to connect directy and hit the firewall.
你在 Linux 上运行吗？ 也许管理代理绑定到本地主机：
http: //java.sun.com/j2se/1.5.0/docs/guide/management/faq.html#linux1
Are you running on Linux? Perhaps the management agent is binding to localhost:
http://java.sun.com/j2se/1.5.0/docs/guide/management/faq.html#linux1
在过去几天对我的 Google-fu 进行了测试之后，在编译了 Stack Overflow 和此页面的答案后，我终于能够让它工作了 http://help.boomi.com/atomsphere/GUID-F787998C-53C8-4662-AA06-8B1D32F9D55B.html。
从 Dell Boomi 页面重新发布：
我没有看到任何 Stack Overflow 答案封面的一行是
在我的例子中，我试图检索 Kafka 指标，所以我只是更改了上面的选项以匹配
-Dcom。 sun.management.jmxremote.port值。 因此，在没有任何类型的身份验证的情况下，最低配置应如下所示：After putting my Google-fu to the test for the last couple of days, I was finally able to get this to work after compiling answers from Stack Overflow and this page http://help.boomi.com/atomsphere/GUID-F787998C-53C8-4662-AA06-8B1D32F9D55B.html.
Reposting from the Dell Boomi page:
The one line that I haven't seen any Stack Overflow answer cover is
In my case, I was attempting to retrieve Kafka metrics, so I simply changed the above option to match the
-Dcom.sun.management.jmxremote.portvalue. So, without authentication of any kind, the bare minimum config should look like this:添加
-Djava.rmi.server.hostname='' 为我解决了这个问题。Adding
-Djava.rmi.server.hostname='<host ip>'resolved this problem for me.尝试使用 Java 8 和更新版本
该解决方案也适用于防火墙
1. 将其添加到远程主机上的 java 启动脚本中：
2. 在您的计算机上执行该解决方案。
Windows 用户：
putty.exe -ssh user@remote-host -L 1616:remote-host:1616Linux 和 Mac 用户：
ssh user@remote-host -L 1616:remote-host:16163. 在计算机上启动
jconsole4. 玩得开心！
PS：在步骤 2 中，使用 ssh 和 -L 指定本地（客户端）主机上的端口 1616 必须转发到远程端。 这是一个 ssh 隧道，有助于避免防火墙或各种网络问题。
Tried with Java 8 and newer versions
This solution works well also with firewalls
1. Add this to your java startup script on remote-host:
2. Execute this on your computer.
Windows users:
putty.exe -ssh user@remote-host -L 1616:remote-host:1616Linux and Mac Users:
ssh user@remote-host -L 1616:remote-host:16163. Start
jconsoleon your computer4. Have fun!
P.S.: during step 2, using
sshand-Lyou specify that the port 1616 on the local (client) host must be forwarded to the remote side. This is an ssh tunnel and helps to avoids firewalls or various networks problems.