性能监控工具 NewRelic 简介

野性酷女 2021-09-07 06:15 433阅读 0赞

**目录**

简介

安装

使用

--------------------

### 简介 ###

NewRelic是一家提供Rails性能监测服务的网站, NewRelic提供了不同级别的监测功能，免费的是Lite版本，最高有Gold版本.

New Relic工具有两种运行模式：

（1）Production 模式：当您的工程以生产模式运行时，您可以在rpm.newrelic.com 网站上实时对它进行监督。

（2）Developer模式：当您的工程以开发模式运行时，您可以在本地localhost:3000/newrelic网页上查看到性能分析数据。

### 安装 ###

New Relic工具安装步骤（默认Rails 3版本）：

1.gem install newrelic\_rpm

2.在Gemfile文件中，添加gem ‘newrelic\_rpm’语句

3．在当前工程下，bundle update

4.在newrelic.com/get-RPM.html注册Lite版本的账号，然后将从此网站下载到的newrelic.yml文件，复制到当前工程的config文件夹中。

5.在development模式下启动工程，访问工程，然后在http://localhost:3000/newrelic页面您会看到对当前工程的性能分析数据。

6.若在production模式下启动工程，则您访问http://localhost:3000/newrelic链接会失效，这时您可以通过https://rpm.newrelic.com/login进行登录，在NewRelic的网站上查看关于工程的性能分析数据。

### 使用 ###

需要关注的是请求的响应时间图表，用这个图表可以对请求在服务器端耗时有个整体印象：

[![B315e203-5433-3aa0-8a28-1ef87c9b70c1][]][B315e203-5433-3aa0-8a28-1ef87c9b70c1]

从图表上可以看到，在这个时间段，请求的平均耗时是52ms，同时可以看到每个请求的Ruby代码和数据库执行时间占据了绝大部分，还有少量的外部服务调用时间（比如第3方Oauth或者API)。由于我们使用OOB GC，所以在图表上几乎没有GC的时间。

另外右上角有一个3.58s的浏览器时间，这个是指用户访问网页，从请求发出，到整个页面完全加载完成（包括图片，css，js等）。

第二个图表是Apdex (Application Performance Index)，从这里可以看到大部分用户是否满意你的应用响应速度：

[![2a4f6da4-3dac-3cd4-bd65-f05075428660][]][2a4f6da4-3dac-3cd4-bd65-f05075428660]

从图表可以看到，99%的用户非常满意请求响应时间（在我们的应用里面，大部分请求是客户端调用api），93%的用户非常满意页面加载完成的时间。我们用的指标是NewRelic默认设置的500ms和7s，你还可以自己进行调整。

第3个图表是吞吐量

[![0dc40e73-6f1b-3599-ae73-6ade99623007][]][0dc40e73-6f1b-3599-ae73-6ade99623007]

可以看出在这半个小时的区间，平均每分钟有1050个请求。用这个图表，通过調整时间段，了解整个应用什么时候是高峰，什么时候是低谷，方便将一些批处理，备份等任务放在访问低谷的时间段进行。

还有当用户报告无法访问的时候，可以通过查看吞吐量是否有急剧下降，来判断是个例还是整体故障，来确定解决问题的优先级。

免费版本的NewRelic，只能查看过去24小时的数据，升级到付费帐号，可以查看所有的历史数据。

第4个图表是根据请求的时间和请求的次数，列出一个最耗时的请求

[![Ffdf1aba-03e5-3962-aab7-5c807272f1bd][]][Ffdf1aba-03e5-3962-aab7-5c807272f1bd]

我们可以根据这个排列顺序，来考虑对于访问量大，同时又耗时的请求进行重点性能优化。  
点击具体的请求，还可以看到请求耗时的分布情况：

![8c9b5712-5bf8-38b8-9905-df348e632a4d][]

从图表上可以看到这个请求，在渲染json数据耗费了比较多的时间，另外在ActiveRecord的查询上也耗费了一些时间，如果要优化的话，就可以从渲染结果加片段缓存，或者查询优化入手。升级到付费版本，还能查看到具体的sql语句执行情况，如果有slow query，还能显示explain的结果。

第5个图表，是错误率

[![101f9130-11e4-341e-b3df-e3054252fd69][]][101f9130-11e4-341e-b3df-e3054252fd69]

在我们应用中引发错误的大部分是一些爬虫404，还有一些是异常数据没有处理好导致，这里就不详细介绍了。这个图表对于用户反馈错误定位也是很有帮助的。

第6个图表，是应用性能分布到各个服务器状态

[![3a4f6585-e5a6-3a4a-bf1a-56049d3af2d9][]][3a4f6585-e5a6-3a4a-bf1a-56049d3af2d9]

对于了解服务器资源和扩容计划很有帮助。顺便说一个实际遇到的事情，发现过某台主机（我们用的云主机）的响应时间就是比其他台要慢50%以上，对比发现这台的CPU和Disk IO都比其他台要弱，后来报告给云主机服务商，通过迁移到了新的物理机解决了。

除了上述的这些性能图表，NewRelic也提供了很多监控的选项，比如ping，内存/存储警报等，可以将报警发送到邮件，或者推送到移动客户端

[B315e203-5433-3aa0-8a28-1ef87c9b70c1]: /images/20210728/9f03a4372fc04d50bff29a7e640388b4.png
[2a4f6da4-3dac-3cd4-bd65-f05075428660]: /images/20210728/ee6a8096dd1947ed80453c794025de1c.png
[0dc40e73-6f1b-3599-ae73-6ade99623007]: /images/20210728/e739708fb0584d8d807e0730c26d35fc.png
[Ffdf1aba-03e5-3962-aab7-5c807272f1bd]: /images/20210728/03920116c7b1463a8faaee91fb328ebb.png
[8c9b5712-5bf8-38b8-9905-df348e632a4d]: /images/20210728/d97b07f16b40466385197bc961dd8007.png
[101f9130-11e4-341e-b3df-e3054252fd69]: /images/20210728/de091d4b3bb34026ae2c79af1eea5bd4.png
[3a4f6585-e5a6-3a4a-bf1a-56049d3af2d9]: /images/20210728/4f8d0150396f42539694a7859289f86f.png