两例访问故障小结

在做运维工作时，或多或少都会遇到访问出错或缓慢问题，这里以两个小的例子来简单说明下这类问题的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的状态,正常。

连接方法:

1

<code>!connect jdbc:hive2:</code><code>/xxxx</code><code>:30000</code><code>/cdnlog</code>

3）查看应用状态，由于是java应用，因此第一时间使用jstat查看下gc信息。发现因为s0和old区100%导致应用在做频繁的full gc,定位到是存在内存泄露的问题，通过jmap打印相关堆栈信息来进一步分析。

2

3

4

5

<code>jstat -gcutil  14266 1000 1000</code>

<code>  </code><code>S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT</code>

<code>100.00   0.00 100.00 100.00  21.65    596   77.267   629 2817.783 2895.050</code>

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的产生

<a href="http://s3.51cto.com/wyfs02/M02/23/EA/wKiom1NGuEbgevnLAAJRoh7dZ1A587.jpg" target="_blank"></a>

即用户到F5正常，由F5到后端nginx出现问题，最终定位到是由于F5配置出错导致proxy到了错误的server上。

存在问题：

1)RST不会在服务器上产生日志，是tcp层面的问题，还没到应用层，因此通过监控nginx的访问日志无法发现这种问题，需要对client端的性能做监控

2）F5的配置有些问题，对于后面机器的检测，只是使用了ping的方法，没有检测端口导致有一部分的请求会分发到有问题的机器（比较理想的请求使用url的应用层检测）

小结：

对于这类问题，可以通过两种方式来troubleshooting，从应用出发和从client端出发。

两种方法的思路都是一样的，首先要清楚的了解整个的访问链，然后对访问进行分解，对每一步都进行检测分析。

同时要注意服务器qos和用户端qos的结合。

本文转自菜菜光 51CTO博客，原文链接：http://blog.51cto.com/caiguangguang/1393707，如需转载请自行联系原作者