理论上，我们需要对系统数据流转的每个节点做监控，收集数据，以便于分析。但是受限于环境问题或者时间问题，我们不能面面俱到，所以需要把系统做一下简单的分类，选择最需要的地方进行监控。
系统资源的监控
对于承载应用的最基础设备，我们需要充分了解它的使用情况，观察其当前的状态，对于硬件设备的评估，也有助于线上设备的采购和选择。一般情况下，我们需要关注的内容有CPU、Memory、I/O、Network，也就是我们通常说的3+1.
注意点：
1、CPU我们关注的是%us（用户使用率），%sy（系统使用率，当需要系统做任务调度的时候会消耗）需要注意。
2、Linux下，空闲Memory的计算方式，基于Linux系统的内存使用原则，不要看到free的数据少了，觉得是瓶颈了。
例如：Total 2G usred 1.5G free 200M buffer 1G cache 500M
系统当前能使用的Memory总量 = free + buffer + cache
3、IO的瓶颈的确认需要特别注意，需要多方考虑，综合思考，"一切问题皆IO"。
4、Network需要注意上下行及单位。
监控工具
Nmon小巧精练的工具，安装和使用都很方便，支持多版本的linux，内容丰富。
最高境界，利用linux自带的命令，通过shell脚本自行采集数据并绘制成图表。常用的命令top、iostat、pidstat、sar、netstat、iftop、vmsata、jstat（jvm使用情况）、jps（java进程）等。
应用层资源的监控
我们可以操作系统的资源消耗，理解为是应用层问题的外在表现。在应用层，由于框架的不同，开发人员水平及意识的限制，会产生各种各样的问题，导致了硬件资源的不合理消耗，从而产生性能问题。在这一层次，我们通常关注以下问题：
1、阻塞，正在运行的线程没有运行结束，暂时让出CPU。
2、争用，多个线程对同一段数据进行不同的操作。
3、死锁，好的线程锁是业务的保障，不好的锁是灾难。
4、理解线程状态图，有助于解决问题。
数据库资源的监控
目前，80%性能问题，会出现在数据库层面。配置不合理；开发人员没有意识，导致SQL执行效率差；线上的大数据量没有提前考虑；不合理的索引等等，都在时时刻刻影响着性能；我们需要重点关注数据库层面的性能问题，关注点以下问题：
1、SQL的执行效率，或者说执行计划。
2、索引的正确使用。
3、大数据量情况下分库分表。
4、其它TOP N的消耗。
数据库监控工具
在oracle数据库中，没什么比AWR报告更好了，看懂了这份报告，基本上足够了。
Msql监控工具MONyog，内容全面，界面清爽，个人强力推荐此工具，从此查看慢SQL不再是体力活。
总结
监控工具没有好坏之分，每个节点选择一款并把它用熟悉，了解每个指标背后的含义，才是正解。我们要做到知其然而知其所以然，这样才能提高自己的判断力，找出问题的根本原因。
性能测试需要丰富的经验，做得越久，你的价值越高。真正的高手会在系统架构之初，就会预期到并解决掉大部分的性能问题。当下，我们不要急功近利，只想学习怎么分析怎么调优，我们需要沉下心来，从小处做起，从基础做起。