响应时间用来衡量应用程序中的事务处理速度，它也可以从 HTTP 请求层和数据库层来观察。有些最慢的查询需要最优化解决，而响应时间可以缩小该查询的范围。吞吐量从另一个角度观察处理过程，并显示应用程序在给定时间域中处理多少请求，通常单位为每分钟（cpm）。
测量响应时间的方法之一就是使用像 New Relic 或者 AppDynamics（就是曾在以前的博客讨论的）那种 APM（应用性能监控工具），通过这些工具，可以追踪平均响应时间，并可以直接在主报告仪表板上与昨日或者上周的平均响应时间作比较，这些比较有助于查看新的部署如何对应用程序造成了影响。另一种方法是通过测量网页处理的百分位数，来测量 HTTP 请求完成响应所需的时间。
也可以内部监测响应时间，但是需要硬代码，例如通过 Dropwizard 指标发送数据并在 Graphite 上发布。尽管看来将这些数据和其他标准关联时会出现最有用的见解，但更多的见解仍涵盖在接下来的方法中。
要点1: 确保所使用的采集方法可以实现从不同角度观测数据，并开始进入百分位层面。
如果你还想使用自带的界面，则需要安装GnuPlot 4.2及以后版本，以及gd和gd-devel等。这里我们选择了GnuPlot 5.0.1的版本。
根据情况执行（没有就装），安装所需软件
$ sudo yum install -y gd gd-devel libpng libpng-devel
之后安装GnuPlot：
$ tar zxvf gnuplot-5.0.1.tar.gz$ cd gnuplot-5.0.1$ ./configure$ make$ sudo make install
安装HBase
首先，确保设置了JAVA_HOME：
$ echo $JAVA_HOME/usr
这个不多说了，非常简单，只需要按照 这里所说，下载、解压、修改配置文件、启动即可。
这时候，再设置HBASE_HOME：
$ echo $HBASE_HOME/opt/hbase-1.0.1.1
之后便可启动hbase：
$ /opt/hbase-1.0.1.1/bin/start-hbase.sh
starting master, logging to /opt/hbase-1.0.1.1/logs/hbase-vagrant-master-localhost.localdomain.out
安装 OpenTSDB
这个也很简单，如果build失败，那肯定是缺少Make或者Autotools等东西，用包管理器安装即可。
$ git clone git://github.com/OpenTSDB/opentsdb.git$ cd opentsdb$ ./build.sh
创建表OpenTSDB所需要的表结构：
$ env COMPRESSION=NONE ./src/create_table.sh2016-01-08 06:17:58,045 WARN [main] util.NativeCodeLoader: Unable to load native-hadoop library for your platform… using builtin-java classes where applicable
HBase Shell; enter ‘help‘ for list of supported commands.
Type “exit” to leave the HBase Shell
Version 1.0.1.1, re1dbf4df30d214fca14908df71d038081577ea46, Sun May 17 12:34:26 PDT 2015create ‘tsdb-uid’,
{NAME => ‘id’, COMPRESSION => ‘NONE’, BLOOMFILTER => ‘ROW’},
{NAME => ‘name’, COMPRESSION => ‘NONE’, BLOOMFILTER => ‘ROW’}0 row(s) in 1.3180 secondsHbase::Table – tsdb-uidcreate ‘tsdb’,
{NAME => ‘t’, VERSIONS => 1, COMPRESSION => ‘NONE’, BLOOMFILTER => ‘ROW’}0 row(s) in 0.2400 secondsHbase::Table – tsdbcreate ‘tsdb-tree’,
{NAME => ‘t’, VERSIONS => 1, COMPRESSION => ‘NONE’, BLOOMFILTER => ‘ROW’}0 row(s) in 0.2160 secondsHbase::Table – tsdb-treecreate ‘tsdb-meta’,
{NAME => ‘name’, COMPRESSION => ‘NONE’, BLOOMFILTER => ‘ROW’}0 row(s) in 0.4480 secondsHbase::Table – tsdb-meta
在habse shell里，可以看到表已经创建成功。
> listTABLE
tsdb
tsdb-metatsdb-treetsdb-uid4 row(s) in 0.0160 seconds
表创建之后，即可启动tsd服务，只需要运行如下命令：
$ build/tsdb tsd
如果看到输出：
2016-01-09 05:51:10,875 INFO [main] TSDMain: Ready to serve on /0.0.0.0:4242
可行工具：
AppDynamics
New Relic
Ruxit
OneAPM
Java应用响应时间和吞吐量
图为 OneAPM 上监控到的 Java 应用程序响应时间和吞吐量
2. 平均负载
第二个广泛使用的衡量指标就是服务器的平均负载。平均负载习惯上分成3部分，在最后的1、5和15分钟（从左到右）显示其结果。只要分数低于机器内核的数量，就是无压力状态，一旦超过内核数，就意味着机器处于压力状态。
平均负载除了可以简单测量 CPU 利用率，更着重于考量每个内核目前在队列中有多少进程。某内核利用率达100%，但是却即将结束任务，而另一内核在队列中还有6个进程要处理，这两种情况是截然不同的。CPU 这一概念并没有涵盖其区别，但是平均负载却可以从大局中考虑此问题。
若在 linux 系统上跟踪平均负载情况，一个极好的方式就是通过 Hisham Muhammad 利用 htop 完成。丰富的色彩加上生动的视觉化效果，瞬间使得命令行有了 NASA 仪表板的即视感。
要点2： 要确定负载，仅靠资源利用率是不够的，还需要格外注意以便充分了解队列中的进程。
可行工具:
htop
htop
图为在一台服务器上运行 htop 以检测负载，平均负载显示在界面的右上角。
3. 错误率（及如处理）
错误率观测有多种方法，而多数开发人员都利用高层次标准——在整个
婚前应用层考察错误率，比如在所有 HTTP 请求中考察失败的 HTTP 处理总数。但是还有一个经常被忽视的具体点：特定事务的错误，这与应用程序的运行状况有直接的影响。代码中某一特定方法失败、生成日志错误及发生异常的次数占总调用次数的比重，也要予以显示。
错误率
图为 OneAPM 对事务中的错误率监控，随时间监控应用错误率情况。
但是这些数据对其本身并没有太大的意义。第一步，从正在处理的事件中优选出最紧急的一件，找到日志错误或异常；第二步，从实际根源处着手，并予以修复。而且基于此问题，已有相应的解决办法。有了 OneAPM ，就没有必要根据日志文件去找错误提示，因为关于服务器状态的所有信息都会在同一界面显示，包括堆栈踪迹、实源代码、变量值及每个错误调用的应用实例。
要点3： 要解决错误率增长的根本原因，仅靠日志文件是不够的，为了得到大量关于我们所需指标的数据，还需要利用一些错误率监控工具。
4. GC率和中止时间
垃圾回收器行为异常，是导致应用吞吐量和响应时间突然下降的主要原因之一。读者想要了解关于垃圾回收过程的更多知识和相关的标准，可阅读 深入理解Java虚拟机（第2版）。
分析 GC 日志文件是理解 GC 中止时间和频率的关键。如果不自行分析，或者使用类似于 jClarity 的工具，这种指标是没有办法直接使用的。所以要确保使用合适的 JVM 参数打开 GC 日志采集，以便分析。
要点4： 请记住，分析不同指标的相关数据，要保持开阔的思维，这样容易发现它们之间的互相影响。
可行工具:
jClarity Censum
GCViewer
