从新手小白到运维大咖，SysOM 多场景宕机实例解析 | 龙蜥技术

文/刘馨蔚，系统运维 SIG Contributor

“老板老板，今天业务又发生了抖动，具体原因暂时还不能快速查清，再给我点时间吧。”

“老板老板，这个问题我好像解过，但是也不太确定，我再重新分析一次吧。”

“老板老板......”

不知道你们或者身边的人是不是也遇到过这个问题：服务器无端重启，造成业务抖动，但是不知道具体发生了什么；明明分析过的问题但是又不能确定是否是同一个问题；无法感知集群的健康状况，无法及时主动地运维。这些问题不仅会影响业务，投入过多的运维人力，无法沉淀已有的运维经验。下文将会从多个场景来展示宕机中心的应用场景。

01 场景 1：运维人员了解集群宕机状况

当发生业务中断、不相应等突发情况时，我们可以通过宕机中心查看当前机器是否存在宕机以及历史宕机，可以快速准确地与现有的业务异常进行关联，同时及时地进行主动运维，减少投入过多人力的排查和时间。宕机中心将会检测并实时收集宕机，及时上报展示到宕机中心首页便于运维人员发现、上报和解决问题。如下图所示，宕机中心的首页除了展示已发生的宕机列表外，还提供了集群的宕机指标和宕机列表信息，其中包括核心指标、总宕机列表和总览集群的宕机状况。使用者可以快速直观地观测到集群的宕机情况，快速了解集群内机器的健康情况。

02 场景 2：新手小白都能看懂的宕机详情与自动关联解决方案

从宕机列表中点击查看某次宕机的宕机详情，将会跳转至宕机详情页面。

宕机详情能为运维新手甚至小白提供能看懂的宕机信息，通过 SysOM 后台自动分析后，在页面展示与以往历史调用栈相同的宕机、宕机的时间、宕机的主机和主机关键信息、宕机的关键函数和运行的进程，硬件宕机还是软件宕机等信息。同时还提供可以在线分析 vmcore 的网页，方便直接快捷地分析问题。

值得一提的是，宕机中心提供了一整套解决方案的管理系统，即使不会分析宕机，也能够快速查看已经关联的解决方案。使用者可通过宕机详情页面的“录入解决方案”按钮来对方案的录入。使用者通过分析宕机后可以将相关的解决方案录入并与某个宕机关联，不仅方便日后查看而且可以记录沉淀这个解决方案，当相似宕机发生时后台会运行宕机相似匹配的算法，自动关联到相似宕机的解决方案。

03 场景 3：运维老手可通过调用栈查询历史的宕机

如果当整个集群的宕机变多后，如何除了利用一些主机名等关键信息来对宕机进行筛选呢？SysOM 宕机中心提供通过调用栈来反向搜索已发生的宕机，这种情况可能发生在查询一台不在 SysOM 管控集群机器的宕机调用栈是否也出现在管控集群的宕机中，或者可以是运维人员想要通过调用栈来直接查找历史宕机。

点击标题上的宕机分析->宕机匹配后跳转到宕机匹配的页面。宕机匹配主要提供了匹配相似宕机的功能，在相似调用栈的文本框中输入某次宕机的关键调用栈，将会和现有历史的宕机进行相似匹配。

如下输入了内核的宕机调用栈后将会在集群内已发生的宕机中搜索相似的宕机，并且给出相似度：

04 场景 4：快速匹配上游社区的问题

虽然 SyOM 提供了一整套解决方案的管理系统，并且相同宕机发生后会自动关联到之前已有宕机的解决方案，但是这套管理系统最开始是没有任何知识库的，需要运维人员分析后，录入知识库不断地积累知识库。为此 SysOM 特有地提供了一种快速匹配上有社区宕机解决方案的方法，在没有任何已知沉淀知识库的情况下也能快速匹配上游社区已知宕机问题的解决方案，同时可以讲匹配到的方案沉淀到自己的知识库中。

例如发生了一个宕机后出现了如下的宕机日志：

[70918341.089708] BUG: unable to handle kernel NULL pointer dereference at (null)

[70918341.098547] IP: [<ffffffffxxxxxxxx>] ovl_cleanup+0x2x/0xd0 [overlay]

...

[70918341.372226] Call Trace:

[70918341.375674] [<ffffffffxxxxxxxx>] ovl_cleanup_whiteouts+0x7x/0xd0 [overlay]

[70918341.383698] [<ffffffffxxxxxxxx>] ovl_clear_empty+0x2x/0x2e0 [overlay]

[70918341.391336] [<ffffffffxxxxxxxx>] ovl_check_empty_and_clear+0x7x/0x90 [overlay]

[70918341.399666] [<ffffffffxxxxxxxx>] ovl_do_remove+0x1x/0x470 [overlay]

[70918341.414296] [<ffffffffxxxxxxxx>] ovl_rmdir+0x1x/0x20 [overlay]

[70918341.421250] [<ffffffffxxxxxxxx>] vfs_rmdir+0xax/0x100

[70918341.427445] [<ffffffffxxxxxxxx>] do_rmdir+0x1ax/0x200

[70918341.447782] [<ffffffffxxxxxxxx>] SyS_unlinkat+0x2x/0x40

[70918341.454124] [<ffffffffxxxxxxxx>] system_call_fastpath+0x1x/0x1b

通过 SysOM 的 Upstream 匹配，可以直接通过宕机日志匹配到上游解决次宕机的方案：

疑似上游社区解决方案：

1.https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux....

2.https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux....

3.https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux....

通过分析后得出第一个上有社区解决方案为本宕机的解决方案。这个上有社区解决方案的匹配搜索方法即将开源到 SysOM 中，欢迎关注与指导。

05 总结

SysOM 的宕机中心是一个集宕机收集、宕机展示和问题匹配的功能平台。宕机中心在提供便捷、用户友好的管理界面同时，也为使用者提供问题积累沉淀、问题智能匹配的功能，实现了更自动化和智能的运维，再也不怕无法及时感知宕机和重复投入已知问题的情况。目前宕机中心的代码已开源到 SysOM 中，欢迎大家点赞批评。（ 系统运维 SIG 主页 ）

可能需要的预备知识：

1、宕机：指操作系统无法从一个严重系统错误中恢复过来，或系统硬件层面出问题，以致系统长时间无响应，而不得不重新启动计算机的现象。

2、宕机信息：主机通过 kdump 等手段，可转储宕机时主机的日志信息和操作系统的 core dump 信息（vmcore），以此来分析宕机的原因。

3、调试 vmcore：类似于 gdb 调试，调试 vmcore 通过 crash 软件来对宕机保存下来的 core 文件进行分析，可分析宕机的宕机函数、调用栈和内存信息等。

4、调用栈：本文中的调用栈都是指宕机时发生异常的 CPU 上的函数调用链，调用栈从下至上的展示了当前的函数调用关系。

—— 完 ——