56做视频网站,国外有哪几家做充电桩网站,wordpress管理软件,武陵天下网站开发序言 学习了一些东西#xff0c;如何才是真正自己能用的呢#xff1f;好像就是看自己的潜意识的反应#xff0c;例如解决了一个问题#xff0c;那么下次再碰到类似的问题#xff0c;能直接下意识的去找到对应的信息#xff0c;从而解决#xff0c;而不是和第一次碰到一样… 序言 学习了一些东西如何才是真正自己能用的呢好像就是看自己的潜意识的反应例如解决了一个问题那么下次再碰到类似的问题能直接下意识的去找到对应的信息从而解决而不是和第一次碰到一样从头开始查一遍如果是那么这个问题对于你来说可能依旧是一个新的问题。 背景把一个应用从一个代理迁移到nginx的时候发现应用偶尔会出现502的响应导致收到告警而在原来中是没有502的而且时间上没有规律数量也比较少。 应用偶发502的排查 1 查看nginx日志 nginx只是一个代理你来什么我就转发什么出现报错的时候第一时间就是查看access log和error log看是否能看到蛛丝马迹。 在accss log中可以看到客户端请求的时间很短基本上是几毫秒就完成了请求也就是request time很短而且502的响应码是upstream status返回的一般我们看到这种的时候我们基本就会认定是后端服务的问题例如后端的cpu/内存有压力导致但是因为是迁移过来的在原来的上面没有此种情况从而开始进一步排查。 对比正常的请求发现qps不高的时候大概只有几十的时候更加容易发生在acess log中不同的地方就是502的响应中upstream_header_time的时间为空而upsteam_response_time为0.001秒或者更短而且出现502之后没有找下一台服务器从而可以认为此时nginx和后端服务已经建立了连接并且传输了数据正常的200响应中upstrem_header_time都是有的另外一个不一样的就是502响应中body_byte_sent都是一个固定值229这个地方比较迷惑的地方是不要认为这是发送给后端服务的body大小而是nginx发送给客户端的body大小nginx的变量命名都是站在nginx本身来说的所以sent表示是发送给客户端的大小。 根据access log能得到有用的信息是和后端服务已经建立连接但是读取头没读取到从而导致出现502bad gateway。 查看error log根据access log找到对应的时间点能看到具体的报错信息 upstream prematurely closed connection while reading response
header from upstream 或者是如下的报错信息 Connection reset by peer) while reading response headerfrom upstream 从而大致可以判断为是nginx的配置中的长连接参数导致连接被上游关闭从而导致响应失败返回502. 2 修改长连接超时参数 在nginx的默认配置中keepalive_timeout为60秒当和后端的连接如果超过了60秒那么nginx会回收这个链接再创建新的连接使用。 对比迁移前的代理查看其中配置的超时时间为20秒从而将超时时间修改为20秒然后再次切换到nginx中观察半小时后发现还是有502的响应询问应用的研发后端框架的超时时间是多久说是20秒发现这个时间时间可能不对从而进行抓包查看。 在容器中抓包比较麻烦容器不能装tcpdump只能到容器所在的物理机上面的网络命名空间去抓包从而使用nsenter进入命名空间抓包因为这个是偶发所以抓包的时间比较长导致这个包会很大。 抓包之后使用wireshark打开在502的包前面服务端的确发送了一个reset包重置了连接。(在此需要注意分析包的时候你会发现nginx和客户端是正常的握手挥手关闭连接不要纠结为啥正常的关闭连接了还能收到502响应) 在对reset包进行查看tcp流的时候查看这个链接的存活时间发现只有5秒而查看其他正常响应的时间也是5秒说明后端的框架中设置的长连接时间为5秒。 继续修改长连接参数为4秒为什么不设置为5秒因为也有可能那么巧合。。。可以看到reset包之前的包nginx已经向后端服务发送了请求包但是后端服务先发了一个fin包然后再发送了reset包从而导致请求发送了但是服务端重置了连接。如果两者的时间相同那么会在极其巧合的时间内导致502如果应用的qps比较高也不会产生502因为连接被快速关闭了。 长连接的时间改的很短造成的影响是如果qps高会频繁的进行创建连接销毁连接影响性能。 至此问题解决从而也可以发现对于长连接来说只要超时时间到了一定会被回收而不管是否还有数据在传输。另外把nginx的时间设置成小于后端服务也让nginx掌握控制权进行连接的管理。超时回收连接的好处就是可以节省系统资源不然会导致很多的连接无法关闭。 当出现问题的时候如何发现问题靠告警 当出现问题的时候如何去解决日志监控 当出现网络问题的时候用什么工具tcpdumpwiresharknetstatss 风言风语 一个正常一个不正常这种排查就很麻烦虽然有对比的数据但是总体的排查还是比较麻烦的而且是偶发偶发的问题总是比直接坏了的情况更加复杂。 当一开始已经判定是这个参数的时候就会去修改这个参数但是实际上修改成多少那就不好猜了最终的定论只能通过抓包来看不是必现的问题抓包都要抓上几个小时枯燥乏味的事情。 当排查一个问题的时候如果百思不得其解那么说明。。。有些基础的概念你不懂要不然的话应该很快能猜到可能出现问题的地方。 AI有决策能力吗但是人肯定有。。。只是你的决策能力的来源于哪里是现实还是一些假大空
