glowroot使用

Posted 2023-05-05

参考技术A

Java 8(agents can still be running under Java 6+)
Cassandra 2.1 or later

如果启动过程没有什么异常的话，那么现在cassandra就已经启动成功了：

Cassandra默认运行在9160端口，我们可以检查一下：
注意 ：Cassandra2.1开始，客户端（cqlsh）默认端口改为9042了,Thrift客户端监听9160端口

显示：

如果想停止的话，直接 Ctrl+C 就可以了。
注： -f 选项指定cassandra在前台运行，如果不加的话会在后台运行
如果要结束在后台运行的cassandra，输入：

查询到该进程的pid，然后kill: $ sudo kill pid

在被监控的应用主机上安装agent：

本次以一个Tomcat应用为例：

配置引入glowroot.jar：

添加以下内容：

保存退出。
注意 ：agent.id要保持唯一。
创建并编辑 glowroot.properties 文件：

写入如下内容

保存并退出。
注意 ：agent.rollup.id可用于跨多个代理(如跨集群)。它可以设置为任何文本(除了不能包含“/”字符,用于多级汇总)。
配置 admin.json ：

修改web，bindAddress为当前服务器地址，保存并退出。
配置Cassandra是否支持密码连接：

默认为允许所有用户连接，不需要账号密码，可以改为

即为需要用户名密码连接。之后启动cassandra服务。
配置Central Collector：

基本是按照默认配置的，ui.https就是安装了中央收集器的ip和端口，这里的用户名密码，如果上面设置了需要密码了连接就在这里配置连接的用户名密码，如果是不需要，注释掉就可以了。
启动：

后台启动：

启动Tomcat应用：

进入ui.https那个地址，可以看到界面啦。

glowroot在使用的过程中，需要保证 agent.id 唯一性，在启动一个应用的多个实例的时候，如果是设置相同的 agent.id 是不被glowroot支持的。

开源JAVA系统监控分析工具Glowroot

目前我们所接触到的系统绝大部分的还是使用Java开发的，因此针对于Java类系统的监控分析需求较大，Java类系统开发依赖的JDK非为常用的两类Sun-JDK和IBM-JDK，大部分的开源工具只是针对于Sun-JDK的，例如本章所讲的Glowroot。

一、简介

Glowroot是一个快速，干净和简单的APM工具。它可以跟踪捕获缓慢的请求和错误，能够记录每个用户的操作时间，以及SQL捕获和聚合。该工具还可保留汇总所有历史数据。

　　它通过图表的方式显示响应时间分布和响应时间百分比，并允许用户通过移动设备监控应用程序性能。

二、Glowroot的使用

2、在启动java程序时加上参数 -javaagent:path/to/glowroot.jar；例如使用的是tomcat的话，在tomcat启动文件中增加以上参数后，重启tomcat。 

3、服务启动之后，确定4000端口启动后，在本地的浏览器中访问 http://localhost:4000就能看到分析界面了（将localhost更换成要监控被测系统的服务器IP）。

一旦工具启动并运行，你将获得能够设置响应时间百分比和MBean属性的警报。Glowroot提供对跨多线程异步请求的全面支持，支持Tomcat，TomEE，JBoss EAP，Wildfly，Jetty和Glassfish等服务器。

三、使用Glowroot监控优化案例

场景：首页接口，涉及的信息有用户信息、可兑换奖品信息、任务列表信息，在高并发的情况下，就会出现性能问题。

2.1 优化之前

1. 调用图分析

[通过jmeter 200 并发的场景下，glowroot工具反馈出的调用图]:

    最左边是一开始的压测图，可以看到jdbc获取连接的时间占用了很大的比例，很明显的连接不够的原因，查看配置文件发现连接只有 5 个，redis连接也只有 10个，配置上之后重新压测结果就是中间的图样，这时瓶颈在jdbc和代码处理了。

1. 最左边是一开始的压测图，可以看到jdbc获取连接的时间占用了很大的比例，很明显的连接不够的原因，查看配置文件发现连接只有 5 个，redis连接也只有 10个，配置上之后重新压测结果就是中间的图样，这时瓶颈在jdbc和代码处理了。

2. sql调用分析

    优化1 : 从图表可看出，兑换奖品表有八千多次查询量，原因①是目前测试环境需要关闭配置隔天生效的设置，每次查询直接查DB，原因②首页的奖品库存需要实时展示，每个用户都会去查询，导致sql调用量增高，可以优化成：从缓存中获取实时库存，定时任务每隔一秒去刷新最新的 数据到缓存中即可，在 1000QPS的场景下，优势就明显多了，原本每秒需要1000次sql查询就缩短成每秒 1次sql查询了。

  优化2：有些表的查询语句，都是同个用户id下进行，不过在不同层调用，这时可以统一优化，上层查询传递到下一层，实现减少调用量的目的。

2.2 第一次优化

1. 调用图分析

    优化效果比较明显，目前只是将兑换奖品缓存规则设置回来还有就是库存实时使用定时任务的方式，db的连接显然减少了一些，不过这时能看到redis的调用时间占比居然很明显，多时达到了几十毫秒，原因可能是项目设置redis连接数不足，或者是该接口对redis操作很频繁。

2. sql调用分析

    可以看到原先兑换奖品现在的查询数量已经降低了很多了，从业务方面也能接受一秒更新一次显示的库存。

四、资源

以下为Glowroot的官方学习资料和实例。

https://glowroot.org/

https://demo.glowroot.org/transaction/average?transaction-type=Web

部分内容原文链接https://blog.csdn.net/larva_s/java/article/details/88876451