关于立维

  • 立维简介
  • 联系我们
  • 新闻动态
  • 技术博客
  • 加入我们
【经验谈】第三期:站群应用并发异常分析
2017-01-06 16:47:51


 本 期 问 题

站群应用并发

如何解决异常报警情况?

  现   象  


20点01分收到一个平时很少更新的网站报警,接着跟他关联的业务也发生报警,第一感觉是是不是客户在更新系统,但紧接着,一堆网站出现异常。

分析思路

1. 首先从大量的网站出现异常上分析,这些应用有什么共通性,是否用了同一个nginx,或者同一台主机,或者同一个数据库。

2. 分析后发现,这些应用都用到了Nginx,应用大多部署在Storemax_OP_01主机上

3. 基于上述两点,我们就要分析nginx是不是挂了,80端口是不是不通

4. 发现nginx一切正常

5. 查看nginx的监控,发现如下两种现象,带宽满了,和nginx并发达到了6000

6.分析nginx日志,查看是否为攻击,由于开始时不知道几十个站点里面,哪个业务出了问题

cat *.access.log|grep "18/Sep/2016:20:0[1-9]"|awk '{print $7}'|sort -rn|uniq -c|sort -rn|head -n10


根据查找出来的访问较高的URL,再去查是哪个应用,由于瞬间产生这么大的访问量,日志的大小肯定会很大。而这些站群中,日志量大的应用不多,很快就查到了是www.storemax.cn这个应用触发的。


紧急处理办法

1. 临时增加一个集群(3分钟时间)

2. 客户那边重启了应用对应的数据库服务器


后续分析

1. 访问频次分析

时间IP数请求数
2016:20:0[0-9]721102915
2016:20:1[0-9]94992154
2016:20:2[0-9]81271881
2016:20:3[0-9]78645769

2. 用户Agent属性分析

从分析结果上看,agent没有

cat www.storemax.cn.access.log|grep "18/Sep/2016:20:[0-2]"|awk '{print $13,$14,$15,$16,$17,$18,$19,$20,$21,$22,$23}'|sort -rn|uniq -c|sort -rn|head -n10


3. 分析agent数过多的访问IP地址来源

cat www.storemax.cn.access.log|grep "18/Sep/2016:20:[0-2]"|grep "iPhone OS 9_3_5 like Mac OS X) AppleWebKit/601.1.46" |awk '{print $1}'|sort -rn|uniq -c|sort -rn|head -n10


4. 分析IP数最多的请求信息

cat www.storemax.cn.access.log|grep "18/Sep/2016:20:[0-2]"|grep "121.32.33.50"|more

从显示的日志上看,用户属于正常访问行为。



综上:

可以基本得出结论,是由于活动推广导致的用户并发突增,从而导致业务不可用。

既然是业务量增大导致的不可用,我们又该如何去优化架构?

是不是增加应用集群就够了?

电话沟通中,客户的业务架构很简单,IIS+SqlServer服务,POST的请求基本都是都是对数据库的操作,有查询,也有插入。

那问题就变得简单了

我们统计这段时间的对数据库的操作的大概次数

时间段POST次数
2016:20:0[0-9]8639
2016:20:1[0-9]13716
2016:20:2[0-9]9407
2016:20:3[0-9]6075

从POST的统计结果来看,是有一定的量,但也不排除数据库中存在SQL性能瓶颈。


比较好的建议:

1. 增加应用集群

2. 增加数据库查询数热点,使用redis或者memcache进行缓存

3. 增加数据库的监控,进一步分析数据库中性能瓶颈

看到这里,小伙伴们有没有觉得茅塞顿开呢?

未来我们还将继续为大家带来技术难题的解决方法

帮助同行的小伙伴们

解决疑难杂症

增长学习经验

摆脱思路困境

丰富实战案例

提供最好的帮助!!!


相信立维,我们还能为你做得更多!

要运维,找立维!

立维,您身边的运维专家!


相关文章