前言:
此刻姐妹们对“pythonserver ready怎么办”大概比较注重,各位老铁们都需要了解一些“pythonserver ready怎么办”的相关知识。那么小编同时在网上收集了一些有关“pythonserver ready怎么办””的相关内容,希望各位老铁们能喜欢,同学们快快来了解一下吧!背景
周一新年第一天上班,我在像往常一样登录测试环境的业务系统时,遇到了404报错。
由于之前也遇到过这个报错,当时是由于登录模块引起的,因此,大概率可以判定这次的报错也是和登录模块有关。前面几次出现问题都是由测试反馈、开发定位解决,为了避免下次再遇到此类问题时无从下手,我决定亲自尝试排查定位一次。
问题排查定位1.理清系统架构业务系统后台与登录系统后台是彼此独立,中间通过网关相互联系。业务系统部署在服务器A,网关和登录系统后台都部署在服务器B,用户数据存储在MongoDB数据库,与业务系统一同部署在服务器A,各个服务器均处于同一内网。
在简单理清逻辑后,我决定从服务器B上的网关和登录后台开始排查。
2.排查登录相关服务① 查看服务器内存
网关和登录系统后台均部署在服务器B,先简单排查一下内存和磁盘。
[root@instance-en0no105 run]# free -m total used free shared buff/cache availableMem: 16045 8188 2974 872 4882 6649Swap: 0 0 0
服务器内存还剩2G多将近3G左右,可以排除内存不足导致的服务异常。
② 查看服务器磁盘
[root@instance-en0no105 run]# df -ThFilesystem Type Size Used Avail Use% Mounted ondevtmpfs devtmpfs 7.9G 0 7.9G 0% /devtmpfs tmpfs 7.9G 0 7.9G 0% /dev/shmtmpfs tmpfs 7.9G 873M 7.0G 11% /runtmpfs tmpfs 7.9G 0 7.9G 0% /sys/fs/cgroup/dev/vda1 ext4 40G 19G 20G 49% /tmpfs tmpfs 1.6G 0 1.6G 0% /run/user/0
磁盘状态正常,没有出现写满的情况,因此也可以排除磁盘可用空间不足的因素。
③ 排查网关
排除内存和磁盘的因素,剩下就是关注各个服务了。查看服务状态最直接的方式就是查看日志,通过tail命令带上200参数可以查看日志文件最近的200条日志,带上f可以查看实时日志,因此可以边操作登录、边查看日志打印情况:
tail -200f Rds_20230130042203.log
发现了以下报错,从报错信息中可以看到socket连接超时了,推测应该是网关没有连上登录后台服务,很可能是登录后台服务有问题。
④ 排查登录系统后台服务
于是,继续排查登录系统后台服务,通过登录后台日志发现连接MongoDB超时了,此时需将排查重点放在服务器A的MongoDB上面。
3.排查MongoDB数据库① 查看服务状态
ps -ef | grep mongo
通过命令发现没有mongo相关进程,可见mongo没有在运行,这也就能解释为什么登录系统后台服务连接失败了。
② 启动mongo服务
bin目录下有很多二进制文件,mongo是客户端,mongod是后台服务
cd /opt/mongodb/bin./mongod # 启动mongod
启动提示数据文件不存在,此前一直正常使用,并没有删除过MongoDB的数据文件。很可能是配置的目录不正确或没有正确加载配置文件。
③ 查看mongo配置文件
查看bin目录下的mongodb.conf
配置文件中的dbPath为/home/soft/mongodb/mongodb3.4.3/data,与报错提示中的/data/db不一致,因此是没有正确加载配置文件,在启动MongoDB时需要指定配置文件启动:
[root@instance-oay02i0j bin]# ./mongod -f mongodb.confabout to fork child process, waiting until server is ready for connections.forked process: 29108child process started successfully, parent exiting
mongo启动成功。
④ 验证服务状态及登录情况
页面再次尝试登录,登录成功。
网关日志正常:
登录后台日志正常:
总结这次的最根本原因是由于MongoDB没有启动,从而导致:登录后台连接MongoDB失败、网关连接登录后台失败,最终导致登录失败。重启MongoDB后一切恢复正常,启动MongoDB时要通过-f参数指定配置文件启动。通过这次排查定位问题,不仅加深了对系统架构的了解,同时也能够避免下次再出现此类问题时麻烦开发、大大提高解决问题的效率。总的来说,这个案例比较短小,排查起来也不是特别复杂,前提是弄清楚系统架构、各个服务之间的相关依赖关系以及一些常用的Linux命令。