在做运维工作时，或多或少都会遇到访问出错或缓慢问题，这里以两个小的例子来简单说明下这类问题的troubleshooting的思路。
1.用户查询平台故障一例
查询平台结构
nginx:80----------ip1/ip2 java------jdbc---(haproxy)--ip3(3000)+ip4(3000)hiveserver2---hdfs
从后端应用开始查：
1）通过hive cli运行sql，检测hadoop运行job的状态，正常。
2）由于应用使用jdbc的方式连接hiveserver2，使用beeline测试hiveserver2的状态,正常。
连接方法:
!connect jdbc:hive2:/xxxx:30000/cdnlog
3）查看应用状态，由于是java应用，因此第一时间使用jstat查看下gc信息。发现因为s0和old区100%导致应用在做频繁的full gc,定位到是存在内存泄露的问题，通过jmap打印相关堆栈信息来进一步分析。
jstat -gcutil 14266 1000 1000 S0 S1 E O P YGC YGCT FGC FGCT GCT 100.00 0.00 100.00 100.00 21.65 596 77.267 629 2817.783 2895.050 100.00 0.00 100.00 100.00 21.65 596 77.267 629 2817.783 2895.050 100.00 0.00 100.00 100.00 21.65 596 77.267 629 2817.783 2895.050
4）再来看nginx的访问日志，可以明显看到nginx首先proxy到ip1，当响应超时后再proxy到ip2，因此从日志中可以看到两个status和upstream response time.
截取的一段日志："8.999, 0.008" "ip1:8081, ip2:8081" "502, 200" "9.007"
存在的问题：
没有有效的java监控（包括性能监控和日志监控）
2.推荐域名访问故障问题
故障现象：
用户访问缓慢，一个url有时响应超过3s，并且会有一定的几率abort.
域名整个的访问流程：
client-----cdn-----内部cdn节点-----源站（F5--nginx---java----redis---db）
从用户端开始入手：
1）通过curl xxxx --trace-time --verbose来查看访问时间的变化情况，单一请求时间3s，渐变点在用户等待服务器响应上
2）用户与cdn服务器连通性没有问题（延迟5ms以内，无丢包），这点从client—cdn建立连接耗时也可以看出来（5ms）
3）源站nginx响应时间2ms，说明后端应用正常，源站到cdn节点延迟是50ms，无丢包,同时看到在cdn内部经过3多层代理，这就导致cdn内部任何一层有问题都会产生慢速响应
4）调整cdn策略为一层代理，问题得到缓解不过还是有一定比例的慢速响应
5）跳过cdn节点，直接指向源站来进行访问测试，发现有一定的几率abort
6）在client端通过tcpdump抓包，发现client---server连接建立正常，但是server端有一定的概率会返回RST给client，造成abort的产生
即用户到F5正常，由F5到后端nginx出现问题，最终定位到是由于F5配置出错导致proxy到了错误的server上。
存在问题：
1)RST不会在服务器上产生日志，是tcp层面的问题，还没到应用层，因此通过监控nginx的访问日志无法发现这种问题，需要对client端的性能做监控
2）F5的配置有些问题，对于后面机器的检测，只是使用了ping的方法，没有检测端口导致有一部分的请求会分发到有问题的机器（比较理想的请求使用url的应用层检测）
小结：
对于这类问题，可以通过两种方式来troubleshooting，从应用出发和从client端出发。
两种方法的思路都是一样的，首先要清楚的了解整个的访问链，然后对访问进行分解，对每一步都进行检测分析。
同时要注意服务器qos和用户端qos的结合。
