WEB 常见故障与处理

一、应用故障

HTTP 502 故障

502 Bad Gateway

故障检测:

首先定位到前端故障服务器节点,在前端服务器(Telnet)上访问后端服务端口响应时间。如发现响应时间超时>10s。说明后端应用程序出现故障。需要到后端服务器查看,并查明情况。

PS:HTTP 502 Bad Gateway 故障一般分为以下2种情况:

网络问题:前端无法连接后端服务,网络100%丢包

后端服务问题:后端服务进程宕掉。如nginx,php进程挂掉。


HTTP 503 

503 Service Temporarily Unavailable

故障检测:

首先定位到前端故障服务器节点,在前端服务器上ping后端服务器查看网络延迟丢包情况,后端服务端口响应时间。如发现延迟>100ms,丢包>5%。说明前端到后端网络出现问题。

PS:HTTP 503 Service Temporarily Unavailable 故障一般是前端访问后端网络延迟导致。首选排查是不是后端流量过载导致。如果不是,就是前端到后端网络问题。

HTTP 504 

504 Gateway Time-out

故障检测:

查看后端服务器Nginx php mysql资源占用情况,并查看相关错误日志。

PS:此类故障几率比较小HTTP 504 Gateway Time-out 故障一般是因的后端服务器响应超时。如PHP程序执行时间太长,数据库查询超时。与程序沟通是否需要增加PHP 执行超时时间。

二、攻击故障

DDOS攻击

故障检测: 

查看监控网卡流量,网络延迟/丢包,数据包个数/s

#iptraf -d eth0 查看网络流量和数据包/s,发现进来的流量和数据包个数非常大,出去的流量和数据包非常小。如下图:

WEB 常见故障与处理

PS:DDOS攻击故障,一般是进来的流量比较大,出去的流量小。网络数据包接收包个数比较大,发送数据包比较小,网络延迟高,并且有丢包现象。

CC攻击故障

故障检测: 查看监控网卡流量,Nginx 连接状态,CPU 负载

WEB 常见故障与处理

WEB 常见故障与处理

PS:CC攻击故障,一般是出去的流量比较大,进来的流量小。Nginx连接数猛增。

原文:https://www.chinasa.net/archives/300.html

原创文章,作者:wubin,如若转载,请注明出处:http://www.178linux.com/17387

(9)
wubinwubin
上一篇 2016-06-03 09:18
下一篇 2016-06-03 09:19

相关推荐

  • Redis高可用架构(1)—Keepalive+VIP

    最近整理一下Redis高可用架构的文档,也准备分享出来,虽然这些架构也不是很复杂。Redis的高可用方案目前主要尝试过5种方式,其中2种方式已经在线上使用。 1)Redis Master-Slave + Keepalive + VIP。这是很经典的db架构,也可以用与mysql的主从切换。基本原理是:Keepalive通过脚本检测master的存活,然后通过…

    Linux干货 2016-04-13
  • OpenStack Icehouse私有云实战部署

    前言 相信你一定对“云主机”一词并不陌生吧,通过在Web页面选择所需主机配置,即可快速定制一台属于自己的虚拟主机,并实现登陆操作,大大节省了物理资源。但这一过程是如何实现的呢?本文带来OpenStack Icehouse私有云实战部署。 OpenStack 简介 OpenStack是由网络主机服务商Rackspace和美国宇航局联合推出的一个开源项目,Ope…

    Linux干货 2015-07-29
  • Linux进程及作业管理总结

    一、简介     在使用Windows操作系统中很多时候需要查看某些程序进程的运行情况,一般来说我们可以打开Windows提供的"任务管理器",然后点击"进程"栏即可查看到当前系统运行的进程列表。例如偶尔出现系统内存、CPU占用过高的时候,我们往往都会查看进程列表,并找到当前占用内存或CPU过高的进…

    Linux干货 2015-10-05
  • lamp平台 php解析器基于模块和php-fpm

    首先,我先介绍一下实验环境: http服务器:192.168.236.128(php解析器基于modules) mysql服务器:192.168.236.129 编译和配置http服务器,http版本是2.4以上的。 由于http依赖于apr apr-util这两个包,但是我们系统上的rpm包版本比较低,我们也需要下载这两个源码包来编译,解决依赖关系。 还要…

    Linux干货 2015-08-31
  • 从Code Review 谈如何做技术

    (这篇文章缘由我的微博,我想多说一些,有些杂乱,想到哪写到哪) 这两天,在微博上表达了一下Code Review的重要性。因为翻看了阿里内部的Review Board上的记录,从上面发现Code Review做得好的是一些比较偏技术的团队,而偏业务的技术团队基本上没有看到Code Review的记录。当然,这并不能说没有记录他们就没有做Code Review…

    Linux干货 2016-08-15
  • 设计模式(十一)代理模式Proxy(结构型)

    1.概述        因为某个对象消耗太多资源,而且你的代码并不是每个逻辑路径都需要此对象, 你曾有过延迟创建对象的想法吗 ( if和else就是不同的两条逻辑路径) ? 你有想过限制访问某个对象,也就是说,提供一组方法给普通用户,特别方法给管理员用户?以上两种需求都非常类似,并且都需要解决一个更大的问题:你如何提供…

    Linux干货 2015-07-09