在做运维工作的时候，或多或少会遇到访问错误或者慢的问题。下面通过两个小例子来简单说明排查此类问题的思路。1、用户查询平台故障查询平台结构示例nginx:80----------ip1/ip2java------jdbc---(haproxy)--ip3(3000)+ip4(3000)hiveserver2---hdfs从后端应用开始查看：1.通过hivecli运行sql，查看hadoop运行job状态，正常。2、由于应用使用jdbc连接hiveserver2，所以使用beeline测试hiveserver2的状态，正常。连接方式：!connectjdbc:hive2:/xxxx:30000/cdnlog3、查看应用状态。由于是java应用，所以第一时间使用jstat查看gc信息。发现应用频繁fullgc是因为s0和old区域100%，定位存在内存泄漏问题，通过jmap打印相关堆栈信息进一步分析。jstat-gcutil1426610001000S0S1EOPYGCYGCTFGCFGCTGCT100.000.00100.00100.0021.6559677.2676292817.7832895.050100.000.00100.00100.0021.6559677.2676292817.7832895.050100.000.00100.00100.0021.6559677.2676292817.7832895.0504、再来看nginx的访问日志，可以明显看到nginx首先proxy到ip1，当响应超时后再代理到ip2，所以可以从日志中看到两个状态和上游响应时间。截取的一段日志："8.999,0.008""ip1:8081,ip2:8081""502,200""9.007"问题：没有有效的java监控（包括性能监控和日志监控）2.推荐域名访问失败问题现象：用户访问速度慢，一个url有时响应3s以上，会有一定概率中止。域名的整个访问过程：client-----cdn-----内部cdn节点-----源站（F5--nginx---java----redis---db）从client端开始：1）通过curlxxxx--trace-time--verbose查看访问时间的变化，单次请求时间为3s，过渡点为用户等待服务器响应时2)用户与CDN服务器的连接没有问题（5ms内延迟，无丢包），这个也可以看到客户端建立连接的时间—cdn(5ms)3)响应源站nginx时间为2ms，说明后端应用正常，源站到CDN节点延迟50ms，无丢包。同时可以看到CDN内部经过3层代理，如果CDN内部任何一层出现问题都会导致响应变慢4）调整CDN策略为一层代理，问题是有所缓解，但仍有一定比例的慢响应5）跳过CDN节点，直接指向源站进行访问测试，发现有一定概率abort6）客户端通过tcpdump抓包，并发现client---server连接正常建立，但是server端有一定概率会返回RST给client，导致abort的产生说明用户正常去F5，F5到后端nginx有问题。最终定位为F5配置错误导致代理上错服务器【问题】1.RST不会在服务器上产生日志，是tcp层面的问题还没有到达应用层，所以通过监控nginx的访问日志是发现不了这个问题的。有必要监视客户端的性能，没有检测端口，所以会分发一些请求到有问题的机器上（理想的请求使用url的应用层检测）【总结】对于这种问题，有两种排查方式，从应用入手和从客户端出发。两种方法的思路是一样的。首先要清楚了解整个访问链条，然后对访问进行分解，对每一步进行检测分析。同时注意服务器qos和客户端qos的结合。
