共计 2962 个字符，预计需要花费 8 分钟才能阅读完成。
文 / 刘馨蔚，零碎运维 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 上的函数调用链，调用栈从下至上的展现了以后的函数调用关系。
—— 完 ——