问题现象
线上环境某个时间出现了系统无法登录的情况,导致了业务服务异常,无法正常登录。
问题排查
通过业务的监控promethus和面板grafana观察node的监控,发现监控中的16:25-16:40之间的数据是中断的。也就是prometehus的pod有问题了收集不到数据。
通过uptime以及last reboot命令查看到19小时之前服务器有重启过,正好对应了grafana监控中有问题的数据的时间段。发现服务器确实存在重启现象。
排查/var/log/message日志,重启时间段没有明显异常。
/var/log/crash
通常是用于存储系统崩溃转储或内核崩溃相关日志的目录。在 Linux 系统中,如果内核崩溃(也称为“内核 panic”),系统可能会生成一个内核转储文件并将其保存在这个目录中。通过分析这些崩溃日志和转储文件,可以帮助诊断和修复导致系统崩溃的问题。
分析//var/log/crash
日志
使用crash工具分析vmcore日志
crash /usr/lib/debug/lib/modules/5.10.0-60.94.0.118.oe2203.aarch64/vmlinux ./vmcore
可以看到引起内核崩溃的任务和原因,命令是khungtaskd,PANIC为"Kernel panic - not syncing: hung_task: blocked tasks"
通过bt命令可以查看具体的调用栈,可以看到_crash_kexec at ffffd53c0a02b2e8
crash> bt
PID: 502 TASK: ffff359dcdbe6040 CPU: 16 COMMAND: "khungtaskd"
#0 [ffff8000131a3af0] machine_kexec at ffffd53c09ebfac4
#1 [ffff8000131a3b40] __crash_kexec at ffffd53c0a02b2e8
#2 [ffff8000131a3cd0] panic at ffffd53c0ab35b0c
#3 [ffff8000131a3db0] check_hung_uninterruptible_tasks at ffffd53c0a071f40
#4 [ffff8000131a3e10] watchdog at ffffd53c0a071ffc
#5 [ffff8000131a3e50] kthread at ffffd53c09f58c88
定位到这个位置,具体引擎内核挂了的原因还不清楚,但是发生了内核恐慌。
[root@node-1 vmcore]# cat /proc/sys/kernel/hung_task_panic
1
决定关闭内核恐慌,将参数设置为0来解决
sysctl -w kernel.hung_task_panic=0