大数据服务部署之问题排查

项目场景：

在部署相关web服务时，出现web页面打不开的问题，在nginx侧与服务侧反复进行查找，都没排查到问题，后通过公司运维支持，快速定位到问题。

问题描述：

部署web服务时，服务端进行命令行测试正常，nginx状态显示也正常，相关端口也开通了的，但是在web页面进行访问时，只加载了部分页面，主要页面并未加载，F12中相关访问资源也没出现明显报错，但是查看nginx状态和nginx日志，都没看出异常。

原因分析：

web服务通常的链路：web（url请求）-> 反向代理（nginx/apache等）-> 服务端 ，如果web访问有问题，通常出现在这三个环节的某一个环节。web端通常会给出最明显的报错信息，比如常见的404、500、505、503等HTTP响应码。本次页面没有报错误码，通过F12查看网络请求资源，也并没有出现明显错误，说明问题不是出在静态资源上。

此时，就需要沿着链路继续排查，就需要查看nginx服务是否正常，并查看nginx对应的访问日志。nginx服务本身并没有问题，查看nignx日志，发现有异常日志（自己对HTTP的有些错误码不够敏感，被忽略了）。

注意，上面在访问 /api/rest_j/v/dss/getBaseInfo 这个接口时，出现499 。通过查阅错误码，了解到：

499对应的是 “client has closed connection”，这很有可能是因为服务器端处理的时间过长，客户端“不耐烦”了。

这说明问题出现在上面端口对应的后段服务上。
然后先telnet host 9020 服务，发现服务端口不通，但是对应服务刚刚启动之后查看状态，明明是正常的啊。那么既然，端口不通而且防火墙未开启，说明服务并未真正起来。
那么，去对应节点查看服务，真的没起来。查看日志，似乎并未其他明显报错，看起来像是正常启动没多久，就被挤掉了。问题很可能出在端口上，该端口被其他服务抢占了。

解决方案：

原来该机器上，有个clickhouse测试服务，是root启动的，每次强杀都没杀死，就把我的服务给挤掉了，把clickhouse服务给真正杀掉之后，问题就解决了。

问题总结：

通常查看日志，日志一般会有明确提示。该服务中日期显示服务先启动后停止，在没有主动停止的情况下，往往是其他服务的干扰，一般首先想到是端口问题。这时，就需要根据每个环节的提示，排查问题原因。