java 获取本机ip_java应用诊断工具Bistoury

Bistoury 是去哪儿网开源的一个对应用透明，无侵入的java应用诊断工具，用于提升开发人员的诊断效率和能力。

Bistoury 的目标是一站式java应用诊断解决方案，让开发人员无需登录机器或修改系统，就可以从日志、内存、线程、类信息、调试、机器和系统属性等各个方面对应用进行诊断，提升开发人员诊断问题的效率和能力。

Bistoury 在公司内部原有agent的基础上集成Alibaba开源的arthas和唯品会开源的vjtools，提供了更加丰富的功能，感谢他们做出的优秀工作。

简介

Arthas和vjtools已经是很优秀的工具，我们为什么还要开发Bistoury？

Arthas和vjtools通过命令行或类似的方式使用，不可否认命令行在很多时候具有比较高的效率；但图形化界面也有其自身的优点，特别是在参数复杂时使用起来更加简单，效率更高。Bistoury在保留命令行界面的基础上，还对很多命令提供了图形化界面，方面用户使用。

Arthas和vjtools针对单台机器，从机器的维度对系统进行诊断，没有提供全局的视角；而在线应用往往部署在多台机器，Bistoury可以和使用方应用中心整合，从应用的维度对系统进行诊断，提供了更多的可能。

Arthas和vjtools在使用上，要么登录机器，要么需要使用者提供相应的ip和端口；Bistoury去掉各种设置，提供统一的web入口，从页面上选择应用和机器即可使用。

除了这些针对性优化，Bistoury在保留arthas和vjtools的所有功能之外，还提供了更加丰富的功能。

Bistoury的在线debug功能去掉了各种复杂参数，模拟ide调试体验，通过web界面提供断点调试的功能，可以在不阻塞应用的情况下捕获断点处的信息(包括本地变量、成员变量、静态变量和方法调用栈)。

Bistoury提供了线程级cpu使用率监控，可以监控系统每个线程的分钟级cpu使用率，并提供最近几天的历史数据查询。

Bistoury可以动态对方法添加监控，监控方法的调用次数、异常次数和执行时间，同时也保留最近几天的监控数据。

Bistoury提供了日志查看功能，可以使用tail、grep等命令对单台或同时对多台机器的日志进行查看。

Bistoury提供可视化页面实时查看机器和应用的各种信息，包括主机内存和磁盘使用、cpu使用率和load、系统配置文件、jar包信息、jvm信息、内存使用和gc等等。

快速开始

Bistoury具有多个模块，并且和公司自身环境有一定的关联，想要合理部署需要进行一些相关的配置。

为了能够快速启动和体验Bistoury，我们提供快速部署脚本在单机部署整套Bistoury服务。

使用快速部署脚本，会在本机部署一整套Bistoury服务，其中包括ui、proxy、agent。

注意，这里提供的快速部署脚本仅适用于快速上手进行单机诊断，想要获得完整的体验，还是需要进行合理的部署。

目前在我们公司内部的使用方式，也是推荐的部署方式为：

• ui独立多机部署，并提供独立的域名
• proxy独立多机部署，并提供独立的域名
• agent在测试环境全环境自动部署，线上环境提供单机一键部署，以及应用下所有机器一键部署
• 独立的应用中心，管理所有功能内部应用和机器信息，这是一个和Bistoury相独立的系统

构建

获取快速部署包

• 我们在项目Release页面提供了已经构建好的快速部署包，你也可以直接下载。
• 你也可以下载源码然后自己构建快速启动包，这同样很简单。首先clone项目到本地，运行script/quick_start_build.sh，运行完成后script目录下会生成相应的快速部署包，名字格式为bistoury-quick-start.tar.gz

准备

• 目前仅支持linux环境，所以需要一个linux环境
• 本机已安装jdk1.8+，并且设置了JAVA_HOME环境变量，如果没有设置也可以在启动脚本中传递参数，详情建下文
• 本机9090，9091，9880，9881端口未被占用，这些端口会被Bistoury使用，如果已占用需要进行配置，详情见下文
• 本机已经启动一个待诊断java应用，如果是spring web应用不需要做处理，非spring web应用需要配置启动脚本的-c参数，详情见下文

启动

首先我们将快速启动包bistoury-quick-start.tar.gz拷贝到想要安装的位置。

然后解压启动包：

tar -zxvf bistoury-quick-start.tar.gzcd bistoury

最后是启动Bistoury，因为Bistoury会用到jstack等操作，为了保证所有功能可用，需要使用和待诊断java应用相同的用户启动。

假设应用进程id为1024

• 如果应用以本人用户启动，可以直接运行

./quick_start.sh -p 1024 start

• 如果应用以其它帐号启动，比如tomcat，需要指定一下用户然后运行

sudo -u tomcat ./quick_start.sh -p 1024 start

• 停止运行

./quick_start.sh stop

访问

可以通过http://ip:9091来对ui进行访问，比如部署的机器ip为192.168.1.20，则可以通过[http://192.168.1.20:9091/](http://192.168.1.20:9091/)访问，初始化用户名密码均为admin

在线debug使用说明

曾经在微博上流传着这么一个程序员才懂的笑话：

NASA要发射一个新型火箭，火箭发射升空后发现不行，NASA把火箭拖回来加了两行log，再次发射，发现又不行，又加了两行log发射，发现又不行....

当然这只是一个笑话，但这样的场景在我们的实际开发中却屡见不鲜，多少次系统重启后问题复现失败，多少次我们解决故障的时间就在不断地加log，发布，加log，发布的过程中溜走...

Arthas的watch命令让我们可以观察函数的入参、返回值、异常等等，然而似乎每次watch都需要看看文档里参数该如何设置，面对函数中的本地变量也是无能为力，特别是行数较多的方法，方法内部的情况还是难以明了。

不过这样的日子已经一去不复返了，Bistoury实现了在线Debug功能，它模拟了ide的调试体验，可以直接在代码上添加断点，甚至还支持条件断点。

断点触发后，Bistoury会捕捉断点处的各种信息，内部状态一览无余。

等等，这似乎就是ide的远程调试功能？

可以说很类似但又不一样：

• 在线debug在使用，功能上和远程调试，或者说你在ide上debug本地代码几乎一致。你在代码某一行打一个断点，断点触发就能看到本地变量、成员变量、静态变量以及调用栈
• 远程调试需要系统启动时就带上调试相关参数，线上应用启动时不可能默认打开调试功能，不说去加上参数然后重启系统的麻烦，重启后你想找的问题可能已经没法复现了；而在线debug不需要应用做任何操作
• 远程调试的断点触发后整个系统会暂停，线上应用这么操作很可能会导致故障；在线debug触发断点后只打印快照信息，打印完后继续执行代码逻辑，不影响系统的运行

看了这么多，不如来上手试一试，用过后你会发现，它就是在调试时你真正想要的那一个！

使用步骤

• 进入在线debug页面，初次使用时请先点击下方链接设置gitlab private token，若不设置，则添加断点时的代码将会通过反编译产生。目前仅支持gitlab，点击输入框下方对应链接获取，然后点击保存设置private token

• 选择需要调试的应用名，再选择需要调试的机器，然后点击【debug】按钮，进入已加载类列表。

• 找到需要调试的类(支持搜索)，点击【调试】按钮进入调试页面。类列表是在attach时获取的应用已加载的类。
• 如果在attach之后有新的类加载(有时在列表中找不到自己想要的类，可能就是你要的类是在attach之后再加载的)，可以通过点击【重新加载】加载按钮对列表进行重新加载。刷新按钮只会重新请求列表，不会重新加载
• 选择“只加载新加载的类”只会加载应用中新加载的类；
• 选择“全部加载”会把整个列表重新加载一遍。
• 找到需要调试的那行代码，点击前方的行号标记设置断点

Q & A

对线上系统影响大吗，不会搞出故障吧？

在线debug已经在去哪儿内部使用较长一段时间，已接受各种线上系统的考验。

在线debug的断点只会触发一次，对于没有触发的调用，不会有任何影响；触发的那一次调用，会多出打印当前快照(本地变量、成员变量、静态变量以及调用栈)的损耗，快照打印完毕后继续执行代码逻辑

代码仓库在github上，每次debug都是反编译的代码，代码仓库能支持其它类型吗？

公司内部使用了gitlab，所以默认就是gitlab，目前刚刚开源，后续会对其它的做支持

条件断点使用说明

断点条件是使用Spring EL表达式来表示的

访问程序中的局部变量使用：localVariables[a]形式，其中a为局部变量的名称 访问程序中的类属性使用：fields[a]形式，其中a为类的属性名 访问程序中的静态变量使用：staticFields[CODE] 形式，其中CODE为静态变量名称 当有多个条件的时候，可以使用：&& || 来进行拼接。只需要使得最终的Spring EL表达式可以计算出一个boolean值就好。

线程级cpu监控

在系统的日常运维中，我们有时会碰到cpu使用率突然飙高的情况。这个时候我们会登录机器，top查看进程id，top -h查看消耗cpu的线程id，然后jstack看看对应的线程是哪一个，最后再进行具体分析。 暂且不考虑这一系列操作需要的时间，我们收到报警的时候可能正在公司外吃饭，或是正在睡觉，而等我们做好准备登录上机器时问题已经结束了，现场没了，我们还能做的就只是看着机器的cpu监控图一脸茫然...

当遇到这些情况时，你会发现你需要的是线程级cpu使用率监控帮你指出问题线程，而不是传统的机器cpu使用率监控让你只能看着监控图一脸懵逼。

Bistoury就是你需要的那一个！我们提供了线程级的cpu使用率监控，它在本地保存了最近三天的线程级监控数据，还对每个线程每一分钟提供一个瞬时的线程调用栈。

系统

目前线程级cpu监控仅支持linux系统，mac系统尚不支持

使用

• 进入主机信息页面
• 选择需要查看的应用、机器
• 点击 【线程级cpu监控】

线程级cpu监控主要分为两个区域，区域一是线程数量和cpu占比的折线图，区域二是线程完整信息。

区域一

可以单独查看某一线程的cpu占比，也可以查看不同时间的cpu占比(支持最近三天)，点击某一时间对应的点，可以在区域二展示具体的线程信息。

区域二

可以按照线程名、线程调用栈、线程状态对线程进行筛选，其中每分钟cpu占用率是该分钟内cpu使用占比，瞬时cpu使用占比，是指抓取数据时cpu瞬时cpu使用率占比。

stacktrace按钮展示

• 命令使用文档

动态监控

有时候我们需要对系统的某个方法添加一个监控看看系统运行情况，但经历一次修改代码、qa检查、重新发布的流程又感觉不划算，这就是动态监控大显身手的时候了。 动态监控类似于Arthas的monitor方法，会对方法的执行时间、调用次数、失败次数进行监控，不同之处在于会生成对应的监控图，保留最近几天的数据，并且提供了web界面，通过类似添加断点的方式来添加监控。

注意： 监控会使用部分应用程序内存，建议内存较小的应用不要添加过多的动态监控。

监控生命周期

动态监控添加的指标生命周期与应用的的生命周期基本一致，从添加开始一直到应用停止，监控回一直采集监控数据。并存储最近三天的历史数据。

使用

• 进入动态监控页面，初次使用时请先点击下方链接设置gitlab private token，若不设置，则添加断点时的代码将会通过反编译产生。目前仅支持gitlab，点击输入框下方对应链接获取，然后点击保存设置private token。

• 选择需要添加监控的应用名，再选择需要在哪台机器上添加监控，然后点击【选择】按钮，进入已加载类列表
• 找到需要添加的类(支持搜索)，点击【监控】按钮进入监控页面。类列表是在attach时获取的应用已加载的类。
• 如果在attach之后有新的类加载(有时在列表中找不到自己想要的类，可能就是你要的类是在attach之后再加载的)，可以通过点击【重新加载】加载按钮对列表进行重新加载。刷新按钮只会重新请求列表，不会重新加载。
• 选择“只加载新加载的类”只会加载应用中新加载的类；
• 选择“全部加载”会把整个列表重新加载一遍。
• 找到需要添加监控的方法，在其中任意语句添加标记，点击前方的行号标记所在行。

• 在监控首页可以选择应用及机器后可以查看监控数据

应用中心

在前面说过，Bistoury不仅仅可以从机器的维度，还可以从应用的维度对系统进行诊断。

应用是什么

我们知道，在线系统往往部署在多台机器上，应用就是与系统相关的这些机器以及所使用到的资源的一个集合。

应用中心就是用来管理应用信息的一个东西，而Bistoury需要从应用中心获取应用与机器、应用与人等各种信息。

Bistoury在ui内部集成了一个简单的应用中心，如果公司内部有自己的应用中心，应该实现bistoury-application-api模块中的接口接入自己的应用中心。

功能说明

应用中心主要职责如下：

• 人/应用/服务器之间的关系
• 应用/服务器的信息

使用说明

• 点击【应用中心】进入应用中心页面，这里会展示当前登录用户的所有应用
• 点击【新增】可以新增一个应用，新增应用时会默认将当前登录用户添加到应用负责人中.
• 点击【管理】可以对应用信息进行管理，可以修改应用信息
• 点击【服务器管理】tab也可以对当前应用的服务器信息进行管理，点击列表中的开关可以对线程级cpu监控等功能进行管理
• 点击新增按钮可以新增服务器，管理按钮可以对服务器信息进行管理。其中端口号用于agent与应用进行连接，日志目录用于查看日志

私信回复"Bistoury"获取链接地址，喜欢的点个关注，一起学习探讨新技术。