用过Jmeter的应该都了解，有个ServerAgent工具，放在linux或者windows服务器上开启服务后，在Jmeter中配置下监视器，就可以抓取到服务器的一些资源信息，抓取的主要是cpu、内存、磁盘、网络等大项，基本够用，肯定是比不上其他的一些资源监控工具详细，但是配置方便啊，拷贝，开启服务就能用，具体的配置过程就不说了，比较好奇实现原理，就研究了下。
分析过程
jmeter运行端就称为客户端吧，ServerAgent所在的机器称为服务端。服务器运行ServerAgent服务后，监听的默认端口是4444。
客户端要拿到服务端的资源数据，肯定是有数据交互的，只不过交互不一定是http协议的，用fiddler可能抓不到通讯过程（实测，确实抓不到）。
那就用万能抓包工具吧，从客户端网卡抓，神器wireshark。
首先搭建好了环境，配置了jmeter测试请求及资源监听，运行并用wireshark抓包，服务器那边是这样的：
从ServerAgent的日志来着，应该是开启监听后，建立tcp连接—>接收test指令测试—>接收cpu、内存等客户端预先配置的监控指标收集命令—>关闭连接，大致是这么个步骤。
那就看看wireshark吧。wireshark是抓整个网卡的，所以一些无效信息会比较多，通过两端的ip过滤，果然找到了4444端口相关的交互信息。
首先，确定通讯协议是tcp。然后就是tcp的三次握手，以及发送test指令，发送资源收集指令，一清二楚。
第一次是客户端发往服务端的，no.57，标识为SYN，表示客户端想要发起连接，带了一个客户端SEQ=0（SEQ随机生成）；
第二次是服务端响应客户端，no.58，标识为ACK，表示服务端的响应，并返回ACK=客户端SEQ+1（本次返回ACK=1），同时带上服务端SEQ=0；
第三次为客户端的确认，no.59，检查ACK是否等于客户端SEQ+1，如果正确，则发送ACK=服务端SEQ+1（本次ACK=1）；服务端收到后，三次握手完成，连接成功；
第四次为发送请求数据，no.60，标识为PSH，表示有请求数据，可以看到确实带了个test指令，只不过是16进制的；
第五次为服务端对test指令的响应，no.61，返回了个Yep；
第六次就是真正的请求资源了，no.62，发了所有配置的资源选项，只不过仍然是16进制的；
至此，工作过程已经很明确了，tcp会一直保持连接，直至主动断开为止，客户端会源源不断接收到服务端的资源数据。
测试
那我们就发tcp测试下吧，把wireshark抓到的16进制拿过来，或者自己把那段资源指标转为16进制，可能有结束符或者空格，转出来不一定对，还是直接照16进制那个抄吧。
把AgentServer重启一下，然后用jmeter创建tcp请求，照着wireshark抄那个请求的16进制Data。
然后运行测试，发现请求会一直执行，直到手动结束测试。看看服务端和得到的响应数据吧。
看这控制台输出，应该是没问题。然后看下jmeter请求的返回值。
返回了不少，不过也是16进制的，当然执行的时间越长，返回的数据量越多。
把16进制解出来看下，嗯没错，就是这些了，按照顺序对到相应的指标上就行了。
这么看，完全可以用ServerAgent做个简单的资源监控系统啊，代码里发请求，解析返回的响应，然后呈现在图像上，易配置，跨操作系统，基本不占资源，想开就开，岂不是美滋滋。