20170413B端业务访问故障排查思路

现象:

1.全国用户电视端页面无法显示,刷不出版面。

2.后端服务无法打开,报错,504,502   显示服务器端业务故障超时。

3.其他业务也出现缓慢情况,并不严重。

排查:

1.系统服务排查,常规负载检查,apache配置,本地curl测试,查看apache进程状态被挂起,发现系统本地访问80端口不通,重启服务无效~ 

2.mysql 数据库未见明显报错异常,刷页面到504页面  应该还没到bd访问,排除数据库问题

3.从多个客户traceroute我们域名来检测下网络,结果都不通..  怀疑网络? 应该不可能  因为网络如果出问题肯定不止我们一个业务出问题。。排除排除。。

4.缩小了范围,那apache为什么一直被挂起,响应超时呢?  发现访问本地的静态文件都无法访问,apache已经完全挂掉了。。

问题发现:

通过大神协助排查,发现程序里面有一个函数一直调用我们新系统业务的一个接口(就是刚刚其他业务也缓慢的原因),因为调用函数里面的curl没有写超时时间,

还有新业务的有两台服务器的SLB超时时间太长了 300s,导致的问题出现。

解决办法:

给curl添加超时时间,将SLB里面的超时时间更改为60s。

时间: 2024-10-12 01:45:37

20170413B端业务访问故障排查思路的相关文章

51CTO学习笔记--Linux运维故障排查思路与系统调优技巧视频课程(高俊峰)

51CTO学习笔记--Linux运维故障排查思路与系统调优技巧视频课程 第一课 Linux运维经验分享与思路 1.一般把主机名,写到hosts下    127.0.0.1    hostname,因为很多应用要解析到本地.oracle没有这个解析可能启动不了. 2.注释掉UUID以及MAC地址,需要绑定网卡的时候,这个可能会有影响. 3.磁盘满了无法启动,  var下木有空间,无法创创建PID等文件,导致文件无法启动,按e   进入single  然后b  重启进入单用户模式. 4.ssh登陆系

AD常见故障排查思路

AD常见故障 活动目录在域环境中起着非常关键的作用,它与各种应用联系紧密,如域用户登录.访问域内共享资源.部署组策略等都需要通过活动目录.活动目录不仅内部的众多功能模块联系密切,而且网络的连通性,网络协议和安全策略等有关,所以处理活动目录时必须综合考虑. 在实际应用中,可能会遇到以下几种AD故障类型. 域连接失败:将计算机加入到域的时候,提示找不到域. 域无法登录:客户端登录域的时候始终提示用户名或密码不正确,或登录域后,无法正常访问网络共享. 域登录缓慢:客户端在登录域的时候非常缓慢,严重影响

F5内网大二层负载均衡业务访问故障解析(CISCO OTV+LISP-MTU问题导致)

一.问题现象 最近在某客户由于假期出现核心CISCO 6509硬件故障当机问题,进而发现F5发布的3个应用访问问题,出现一部分人访问应用出现不可用的问题,时好时坏,内网使用F5 GTM+LTM进行域名双活,内部同城双活DC通过三层路由使用CISCO的大二层技术OTV+LISP技术构建: F5上面检查应用不管是VS还是pool member都是正常,health check or monitor算法采用TCP:通过将LTM双机上面对端DC业务member 进行offline,GSLB的跨DC me

cpu突然飙升故障排查思路

处理过线上问题的同学基本上都会遇到系统突然运行缓慢,CPU 100%,以及Full GC次数过多的问题. 当然,这些问题的最终导致的直观现象就是系统运行缓慢,并且有大量的报警. 本文主要针对系统运行缓慢这一问题,提供该问题的排查思路,从而定位出问题的代码点,进而提供解决该问题的思路. 对于线上系统突然产生的运行缓慢问题,如果该问题导致线上系统不可用,那么首先需要做的就是,导出jstack和内存信息,然后重启系统,尽快保证系统的可用性. 这种情况可能的原因主要有两种: 代码中某个位置读取数据量较大

论运维之故障排查思路与方法

运维故障思路剖析: 1.出了问题冷静分析,仔细听通告者描述的问题,勿要慌张理清思路 2.根据描述问题查看相应的服务有没有端口.后台是否有运行的程序.防火墙的策略.网络问题.报错日志 3.如若有些开源软件需要连接至数据库,在看数据库的端口.后台运行的程序,是否能登录 4.一般到了这一步就是疑难问题啦!仔细分析报错日志的提示方向,范围想的广一些,若一些网页访问不到, 表面上没报类似于404,403之类的错误,而是直接访问错误,排除host绑定,nginx代理问题后,就要把故障定位到数据库啦! 因为应

Java进程故障排查思路及步骤

故障场景 Java进程出现问题,通常表现出如下现象: Web应用响应时间长/超时,甚至不响应 CPU使用率极高/低,频繁出现Full GC,甚至OutOfMemoryError 响应时间长.超时,甚至不响应,这是最直观的表现:而CPU使用率极高或极低,频繁出现Full GC,这些需要借助系统日志或者监控辅助发现. 原因分析 针对响应时间长.超时,甚至不响应,这是一个综合性的问题导致的,可能并不单纯是应用程序本身的问题,如果后端还接了数据存储系统,除了排查应用程序本身的问题之外,还需要排查应用所依

Linux系统运维故障排查思路

一些处理问题的一般思路   1)重视报错提示信息,每当错误出现,都会给出错误提示信息,一般情况下,这个提示基本定位了问题的所在,因此一定要重视这个报错信息,如果对这些错误信息视而不见,问题永远都得不到解决.   2)查询日志文件.有时候报错信息只是给出了问题的表面现象,要想更深入的了解问题,必须查看想应的日志文件,二日志文件有分为系统日志文件(/var/log),和应用程序日志文件,结合这两个日志文件,一般就能定位问题所在.   3)分析定位问题.这个过程是比较复杂的,根据报错信息,结合日志文件

Linux运维故障排查思路

linux系统故障 网络问题 linux系统无响应 linux系统无法启动 linux系统故障处理思路 1.重视报错信息,一般情况下此提示基本定位了问题的所在 2.查阅日志文件,系统日志和应用日志 3.分析.定位问题 4.动手解决 网络问题处理思路 1.网络硬件问题.网线.网卡.路由器.交换机等是否正常工作. 2.网卡驱动是否正常加载.网卡ip设置是否正确,系统路由是否正确. 3.检查局域网之间的通信是否正常. 4.检查dns是否设定正确.可从/etc/resolv.conf./etc/host

光缆故障排查思路及解决方式

第一个问题:光缆的区别?1.外观2.传输距离3.波长4.芯径    第二个问题:两台交换机如何通过光缆进行互联?1.光缆(明确光缆的类型.长度)1.交换机2.光模块(明确光模块的类型.速率)3.光纤跳线 (明确跳线的类型.长度.速率)5.耦合器(明确耦合器的类型)6.尾纤(明确跳线的类型.长度.速率)7.光纤配线架或者光纤终端盒(明确具体的类型)第三个问题:上述两台交换机之间无法通信?1.交换机的带电状态---->交换机接口故障--->替换法2.接口状态-->down3.检查模块--&g