生产系统出的问题中，请求响应慢是很常见的问题，如何快速定位慢的源头非常重要，通过对之前遇到的问题总结，发现一般都是依赖服务慢或者出现线程阻塞导致，对于这两种问题简单有效的定位方法如下：
1、打印超过阀值的依赖服务访问时长到日志，通过日志定位
2、使用java的jstack命令查看java线程是否阻塞
其中简单介绍一下如何利用日志定位问题：
对每个项目依赖的服务，比如：http，redis，hbase，mysql，memcached，kafka添加访问时长的日志，对超过设置阀值的信息输出到同一个单独的日志文件中，当出现服务慢等问题时，打开该文件就可以很快定位慢的是哪个服务，具体做法是在common项目中提供对相关服务的封装，应用通过封装类进行服务交互。
日志文件内容举例如下：
10:40:00.661 [http-bio-28000-exec-8] url http://217.0.0.1:8080/demo?p=1 response time > 300 ms , 362 ms
11:19:29.070 [http-bio-28000-exec-1] hbase table cloud_usr_book_3 getRowResultsByRowkeyRangeAndColumnNames nayoaixij_ nayoaixij_| columnNames count:1 2147483647 response time > 100 ms , 125 ms
11:45:02.924 [Thread-56] redis 192.168.7.122 6429 0 lpop nc_pre_ajbal response time > 20 ms , 21 ms
该日志中只包含慢的请求，通过该日志一眼就能看出是具体哪个http服务或者redis或者hbase等慢，当然也有可能不是某个服务慢而是系统内部问题，比如有一次由于日志打印过多导致出现了logback的阻塞，这时通过jstack就可以定位到具体问题，关于打印日志有3点需要注意：
1、线上日志级别调整为info，线上查错的日志以info的级别输出
2、输出到线上日志文件的内容需精细化控制，比如：在调用外部系统的bookDetail服务会返回图书的详细信息，该信息一共80多个字段，平均4K，不能全部输出，只输出业务用于查错的部分字段
3、如果有多个文件的appender，如果不需要输出到root的appender，则应该设置logger配置项的additivity属性为false，避免同一份日志写两个日志文件，比如：
