写点什么

网易轻舟云原生故障自动诊断系统实践

  • 2020-07-08
  • 本文字数:8804 字

    阅读完需:约 29 分钟

网易轻舟云原生故障自动诊断系统实践

Kubernetes 是一个生产级的容器编排引擎,但是 Kubernetes 仍然存在系统复杂、故障诊断成本高等问题。网易内部在基于 Kubernetes 落地轻舟云原生体系时遇到了不少问题,主要包括以下几个维度:


  • 由 Kubernetes 以及 Docker 的 Bug 引起的故障。

  • 内核 Bug 导致的故障。

  • 基础设施抖动产生的问题。

  • 用户在容器化以及使用 Kubernetes 过程中遇到的问题。

  • 用户在容器化后遇到的业务相关问题。


Kubernetes 故障诊断恢复平台是基于 Kubernetes 云原生基础设施能力打造的框架,旨在解决云原生体系中故障诊断、运维恢复的自动化问题,帮助用户更加平滑地完成容器化落地。

目标

Kubernetes 故障诊断恢复平台的设计目标包括:


  • 通用性:平台依赖通用技术实现,平台组件可以在绝大部分的 Linux 系统下运行并且能够对 Linux 下运行遇到的故障进行诊断和运维。

  • 可扩展性:平台组件之间的交互为松耦合接口设计并且整个框架是可插拔式的。

  • 可维护性:框架逻辑简洁明了,维护成本与功能数量为线性关系,不同故障的分析和恢复逻辑具有独立性。

架构

故障诊断恢复平台 Agent 组件可以监听 APIServer 获取 Abnormal CRD 资源,Abnormal CRD 资源是对故障状态机的抽象。故障诊断恢复平台 Agent 组件可以通过 Event、Prometheus 报警、系统日志中的关键条目产生相对应的 Abnormal CRD 并送入故障诊断恢复的流水线。故障诊断恢复平台 Agent 组件使用 DaemonSet 部署在集群中:


                                                         ---------------------                                     Watch (Event, CRD)  |                   |                                   --------------------->|     APIServer     |                                   |                     |                   |                                   |                     |-------------------|                                   |                     |                   |--------------                 ---------                 |       Etcd        ||            |     Monitor     |       |     Monitor     |                   || Prometheus |<----------------| Agent |---------------->|-------------------||            |                 |       |                 |                   |--------------                 ---------                 | ControllerManager |                                   |                     |                   |                                   |                     |-------------------|                                   |                     |                   |                                   |                     |     Scheduler     |                                   |                     |                   |                                   |                     ---------------------                                  \|/                         ---------------------                         |                   |                         |      Kernel       |                         |      Docker       |                         |      Kubelet      |                         |      Cgroup       |                         |      ......       |                         |                   |                         ---------------------
复制代码


故障诊断恢复平台 Agent 组件由下列部分组成:


  • 故障事件源(AbnormalSource)

  • 故障分析链(DiagnoserChain)

  • 信息管理器(InformationManager)

  • 故障恢复链(RecovererChain)


    ------------------             ----------------------             ------------------             ------------------    |                |  Abnormal   |                    |  Abnormal   |                |  Abnormal   |                |    | AbnormalSource |------------>| InformationManager |------------>| DiagnoserChain |------------>| RecovererChain |    |                |             |                    |             |                |             |                |    ------------------             ----------------------             ------------------             ------------------                                              |                                |                              |                                              |                                |                              |                                              |                                |                              |                                             \|/                              \|/                            \|/                                 --------------------------             ---------------                ---------------                                 |                        |             |             |                |             |                                 | InformationCollector 1 |             | Diagnoser 1 |                | Recoverer 1 |                                 |                        |             |             |                |             |                                 --------------------------             ---------------                ---------------                                              |                                |                              |                                              |                                |                              |                                              |                                |                              |                                             \|/                              \|/                            \|/                                 --------------------------             ---------------                ---------------                                 |                        |             |             |                |             |                                 | InformationCollector 2 |             | Diagnoser 2 |                | Recoverer 2 |                                 |                        |             |             |                |             |                                 --------------------------             ---------------                ---------------                                              |                                |                              |                                              |                                |                              |                                              |                                |                              |                                             \|/                              \|/                            \|/                                           .......                          .......                        .......
复制代码

功能

故障诊断恢复平台 Agent 组件功能如下:


  • 获取 Event、Prometheus 报警、系统日志作为故障源。

  • 监听故障诊断 Abnormal CRD 资源并进行处理和状态同步。

  • 对本节点故障进行诊断和恢复。

  • 通过 Abnormal CRD 以及 InformationCollector CRD 进行监控扩展和增强。


故障诊断恢复平台中 Abnormal 的状态迁移流程如下:


  • 故障事件源监听到 Event、Prometheus 报警、系统日志等异常,故障诊断恢复平台 Agent 或用户自行创建 Abnormal CRD 资源。

  • 将 Abnormal 发送至信息管理器,标记 Abnormal 的状态为 InformationCollecting 并采集故障诊断恢复的信息。

  • 如果信息能够被成功收集则记录 InformationCollected 状况并继续。

  • 将 Abnormal 发送至故障分析链,标记 Abnormal 的状态为 Diagnosing 并对故障进行分析。

  • 如果故障能够被成功识别则记录 Identified 状况并继续。

  • 如果故障无法被成功识别则将 Abnormal 的状态标记为 Failed 并终止故障诊断恢复流程。

  • 将 Abnormal 发送至故障恢复链,标记 Abnormal 的状态为 Recovering 并对故障进行恢复。

  • 如果故障能够被成功恢复则记录 Recovered 状况并标记 Abnormal 的状态为 Succeeded。

  • 如果故障无法被成功恢复则标记 Abnormal 的状态为 Failed 并终止故障诊断恢复流程。


故障诊断恢复平台中 Abnormal 的状态迁移图如下:


                                                                                                                                             ----------                                                                                                                                             |        |                                                                                 ----------------------------------------------------------->| Failed |                                                                                /|\                              /|\                         |        |                                                                                 |                                |                          ----------                                                                          Failed |                         Failed |                                                                                 |                                |-----------                   -------------------------                   --------------                   --------------                   -------------|         |                   |                       |                   |            |                   |            |                   |           || Created |------------------>| InformationCollecting |------------------>| Diagnosing |------------------>| Recovering |------------------>| Succeeded ||         |                   |                       |       /|\         |            |       /|\         |            |       /|\         |           |-----------                   -------------------------        |          --------------        |          --------------        |          -------------                                          |                    |                 |              |                 |              |                             Successfully |                    |    Successfully |              |    Successfully |              |                                          |                    |                 |              |                 |              |                                         \|/                   |                \|/             |                \|/             |                               ------------------------        |          --------------        |           -------------        |                               |                      |        |          |            |        |           |           |        |                               | InformationCollected |---------          | Identified |---------           | Recovered |---------                               |                      |                   |            |                    |           |                               ------------------------                   --------------                    -------------
复制代码

Abnormal CRD

Abnormal 是故障诊断恢复平台中故障事件源、故障分析链、故障恢复链之间通信的接口。故障事件的详情记录在 Spec 中,故障事件源、故障分析链和故障恢复链对 Abnormal 进行处理并通过变更 Status 字段进行通信。故障诊断恢复平台通过 Abnormal 提供以下功能:


  • 记录故障现象和来源,故障事件源会在接收到故障事件后将现象和来源写入 AbnormalSpec 中。

  • 维护故障恢复的状态机,故障事件源、故障分析链、故障恢复链会在对故障恢复后将结果更新到 AbnormalStatus 中。

  • 在节点上或容器内执行探测指令,如运行命令或者发送 HTTP 请求,并将结果输出到 AbnormalStatus 中。

  • 故障分析链将 Abnormal 逐个发送至故障分析器,故障分析器分析后输出 Abnormal,故障分析链对输出的 Abnormal 进行验证后决定下一步流程。如果 Abnormal 被成功识别则更新 AbnormalStatus 并将 Abnormal 发往故障恢复链。如果无法识别或者发生错误则更新 AbnormalStatus 并等待人工干预。

  • 故障恢复链将 Abnormal 逐个发送至故障恢复器,故障恢复器恢复后输出 Abnormal,故障恢复链对输出的 Abnormal 进行验证后决定下一步流程。如果 Abnormal 被成功恢复则更新 AbnormalStatus。如果无法恢复或者发生错误则更新 AbnormalStatus 并等待人工干预。

Abnormal

Abnormal 是故障诊断恢复平台中故障事件源、故障分析链、故障恢复链之间通信的接口,用于描述故障。


FieldDescriptionSchemeRequired
metadataAPI 资源元数据。metav1.ObjectMetafalse
spec故障的来源和现象说明。支持用户自定义字段。AbnormalSpectrue
status故障当前的状态。由故障事件源、故障分析链、故障恢复链维护,用户无法自行修改。AbnormalStatustrue

AbnormalSpec

FieldDescriptionSchemeRequired
source故障的来源。该字段支持 Log、KubernetesEvent、PrometheusAlert、Probe 和 Custom。stringtrue
log表示故障的日志详细信息,对应 source 字段的 Log。Logfalse
kubernetesEvent表示故障的 Kubernetes Event 详细信息,对应 source 字段的 KubernetesEvent。corev1.Eventfalse
prometheusAlert表示故障的 Prometheus Alert 详细信息,对应 source 字段的 PrometheusAlert。PrometheusAlertfalse
nodeProbe用户自定义的节点故障探测 Probe,支持 Probe 类型故障。NodeProbefalse
podProbe用户自定义的容器故障探测 Probe,支持 Probe 类型故障。PodProbefalse
skipDiagnosis跳过故障分析步骤。boolfalse
skipRecovery跳过故障恢复步骤。boolfalse
nodeNameAbnormal 所在节点名。stringfalse
assignedDiagnosers指定进行诊断的故障诊断器列表。[]NamespacedNamefalse
assignedRecoverers指定进行恢复的故障恢复器列表。[]NamespacedNamefalse
assignedInformationCollectors指定进行信息采集的信息采集器列表。[]NamespacedNamefalse
context用于扩展的上下文信息,支持 Custom 类型故障。runtime.RawExtensionfalse

Log

FieldDescriptionSchemeRequired
filePath日志文件的绝对路径。stringtrue
logEntry日志中表示故障的条目。stringtrue

PrometheusAlert

FieldDescriptionSchemeRequired
labelsAlert 的标签。labels.Labelstrue
annotationsAlert 的注解。labels.Labelstrue
startsAt告警的开始时间metav1.Timefalse
endsAt告警的结束时间metav1.Timefalse
generatorURL告警生成者的 URLstringfalse

NodeProbe

FieldDescriptionSchemeRequired
name执行 Probe 的 Node。stringtrue
timeoutSecondsProbe 执行超时时间。int32false
execExec 命令。corev1.ExecActionfalse
httpGetHTTP 请求。corev1.HTTPGetActionfalse
tcpSocketTCP 探活。corev1.TCPSocketActionfalse

PodProbe

FieldDescriptionSchemeRequired
namespace执行 Probe 的 Pod 命名空间。stringtrue
name执行 Probe 的 Pod。stringtrue
container执行 Probe 的容器。stringtrue
timeoutSecondsProbe 执行超时时间。int32false
execExec 命令。corev1.ExecActionfalse
httpGetHTTP 请求。corev1.HTTPGetActionfalse
tcpSocketTCP 探活。corev1.TCPSocketActionfalse

AbnormalStatus

FieldDescriptionSchemeRequired
identifiable表示该故障为可以被故障分析器识别的故障。booltrue
recoverable表示该故障为可以被故障恢复器恢复的故障。booltrue
conditions描述故障恢复流程中关键点的状况。[]AbnormalConditionfalse
phase故障的当前阶段。该字段支持 InformationCollecting、Diagnosing、Recovering、Succeeded、Failed、Unknown。stringfalse
message表示当前故障恢复阶段的可读信息。用于输出故障原因、故障恢复建议等。stringfalse
reason表示当前故障恢复阶段的简短信息。stringfalse
outputExec 命令、HTTP 请求、TCP 探活的输出。stringfalse
startTime表示当前故障开始被诊断的时间。metav1.Timefalse
diagnoser成功执行的故障诊断器。NamespacedNamefalse
recoverer成功执行的故障恢复器。NamespacedNamefalse
context用于扩展的上下文信息,支持 Custom 类型故障。runtime.RawExtensionfalse

AbnormalCondition

FieldDescriptionSchemeRequired
type故障状况的类型。stringtrue
status故障状况的状态。该字段支持 True、False、Unknown。stringtrue
lastTransitionTime上一次状况的状态变化时间。metav1.Timefalse
message表示当前状况的状态变化原因的可读信息。stringfalse
reason表示当前状况的状态变化原因的简短信息。stringfalse

NamespacedName

FieldDescriptionSchemeRequired
namespaceAPI 资源的命名空间。stringfalse
nameAPI 资源的名称。stringtrue

故障事件源

故障事件源是获取故障事件的接口,大致可分为以下几类,每一类都需要实现故障事件源接口:


  • 日志:日志是获悉集群发生故障的重要手段,通过监听内核、Kubernetes 以及 Docker 日志中的异常字段可以在第一时间发现故障并进行处理。

  • Prometheus:Prometheus 满足云原生体系中绝大部分组件的监控需求,大部分组件的内部异常可由 Prometheus 接口暴露。

  • Event:Kubernetes 中的事件支持更细致的故障上报机制。

  • CRD:CRD 用于自定义故障,用户可以自定义进行扩展。


故障事件源在消费日志、Prometheus 报警和 Event 后会生成 Abnormal 故障事件并发往故障分析链。用户也可以直接通过 CRD 来创建故障事件。

故障分析链

故障分析链是一个调用链框架,本身并不包含故障分析的逻辑,用户需要实现故障分析的具体逻辑并注册到故障分析链中。故障分析链从故障事件源接收故障事件并将故障事件逐一传入被注册的故障分析器中,当故障事件能够被某个故障分析器识别则中止调用并交由该逻辑进行处理。如果故障无法被任何故障分析器识别则直接获取相关排障信息并报警。故障分析器一般是一个 HTTP 服务器。用户可以将自定义故障诊断分析的脚本放入特定路径,故障分析链会动态的获取自定义故障诊断分析文件。


故障分析器在无法识别 Abnormal 故障事件时返回错误,故障分析器在成功识别 Abnormal 故障事件后变更 Status 字段。故障分析链在某个故障分析器成功识别 Abnormal 故障事件后将 Abnormal 故障事件发往故障恢复链。故障分析器在执行诊断时可以通过调用信息采集器获取更多信息。

信息管理器

当故障分析或恢复流程较复杂时,需要从其他接口获取更多信息用于故障的诊断和确认。此时故障分析器或故障恢复器可以调用信息采集器获取更多信息。常用的信息采集器包括 eBPF、Golang 剖析文件、Java 虚拟机工具等。信息采集器一般是一个 HTTP 服务器。故障分析器或故障恢复器需要保证能够正确处理从信息采集器获取的信息。信息管理器用于管理多个信息采集器,用户通过请求信息管理器获取额外信息,信息管理器在接收到请求后会转发到相应的信息采集器中。

故障恢复链

和故障分析链相似,故障恢复链也是一个调用链框架,本身并不包含故障恢复的逻辑,用户需要实现故障恢复的具体逻辑并注册到故障恢复链中。故障恢复链从故障分析链接收故障事件并将故障事件逐一传入被注册的故障恢复器中,当故障能够被某个故障恢复器识别则中止调用并交由该逻辑进行处理。如果故障无法被任何故障恢复器识别则报错中止。故障恢复器一般是一个 HTTP 服务器。用户可以将自定义故障恢复的脚本放入特定路径,故障恢复链会动态的获取自定义故障恢复文件。

典型用例

社区 Issue 3529 中记录的 Bug 会导致 Docker 18.06 及以下版本因为 Shim 的死锁而无法正常终止容器。当该故障出现时可以通过以下步骤实现该故障的诊断恢复:


  • 实现故障事件源:获取当前 Terminating 状态的 Pod,当该类 Pod 存在时创建表示该故障的 CRD,标记 .spec.nodeName 字段为该 Pod 所处节点。

  • 实现故障分析器:首先通过进程树查找到该容器对应的 Shim 进程。然后向该 Shim 进程发送 SIGUSR1 信号获取栈信息,在栈信息中查找 reaper.go 相关函数以确定问题原因。

  • 实现故障恢复器:杀死该容器对应的 Shim 进程进行恢复。


作者简介:


黄久远,网易杭州研究院轻舟云原生资深研发工程师。专注于云原生以及分布式系统等领域,作为核心成员参与了网易集团内部容器化落地以及网易轻舟容器平台产品化。目前主要负责网易轻舟云原生故障自动诊断系统的设计、开发以及商业化产品输出等工作。


2020-07-08 16:514078

评论 3 条评论

发布
用户头像
后续是否还有持续开发和运营这个系统,有没有更多实践经验可以分享。
2023-08-10 21:03 · 广东
回复
用户头像
将 Abnormal 发送至信息管理器,标记 Abnormal 的状态为 InformationCollecting 并采集故障诊断恢复的信息。
如果信息能够被成功收集则记录 InformationCollected 状况并继续

这个是关键啊。通常失效原因不是一个,或者称为dominate failure cause. 所以,大多数失效很难确定单一原因,尤其是软件,基本上都是 hidden failure.那么,这种自动恢复的适用场景是不是会比较窄?

Andrew
展开
2020-07-08 20:41
回复
谢谢。实际上这个问题我们有考虑的:
* Abnormal 的 `assignedInformationCollectors` 字段是一个列表,用户在创建 Abnormal 的时候是可以指定多个 Collector 的。问题发生时主要依赖 Diagnoser 的实现进行故障诊断,Diagnoser 本身的标准是比较开放的,唯一的要求就是 Diagnoser 必须是一个接受 Abnormal 数据结构的 HTTP 服务器。Diagnoser 在获取到 Abnormal 后可以从 `context` 中查找需要的信息,也可以在 Diagnoser 这一层实现查找信息的功能。这样开发者可以获取尽可能多信息并且保证了一定的灵活性,并不局限于单一的原因。
* 故障诊断平台的设计定位是解决已知问题集的。所有可以自动诊断并恢复的故障都是可以通过技术手段确定的。典型用例中列举的场景是一个例子,我们在这个场景下通过 Shim 的栈信息找到相关代码确定问题原因来保证不触发误诊。如果故障是一个未知问题或者很难确定单一原因的问题,那么我们依赖的是人工介入排障而不是自动诊断恢复,在人工介入将问题理清后再将诊断流程代码化。在生产实践中我们发现这是比较稳妥并且合理的。
展开
2020-07-10 17:13
回复
没有更多了
发现更多内容

Web网页端IM产品RainbowChat-Web的v7.2版已发布

JackJiang

即时通讯;IM;网络编程

Meta 最新 SPIRIT-LM:语音文本无缝转换还能懂情绪;字节回应实习生破坏大模型训练:网传损失不实丨 RTE 开发者日报

声网

华为云架构师深度解读Volcano云原生混部解决方案

华为云开发者联盟

云原生 Volcano 资源调度

VMware ESXi 8.0U3 macOS Unlocker & OEM BIOS 2.7 Dell HPE 定制版 9 月更新发布

sysin

macos windows esxi OEM 2.7

冲击美团!已成功 OC

王中阳Go

Go 面试 后端

2024年游戏买量应该怎么玩?

FinFish

小程序容器 游戏买量 小游戏技术 快平台游戏买量

Web3 游戏周报(10.13 - 10.19)

Footprint Analytics

链游

VMware ESXi 8.0U3 HPE (慧与) 定制版更新 OEM BIOS 2.7 支持 Windows Server 2025

sysin

macos windows esxi OEM 2.7

比特币矿工该如何选择矿池?请收下这份 2024 年六大比特币矿池指南

TechubNews

DApp众筹项目互助模式系统开发详细步骤与功能设计

区块链软件开发推广运营

交易所开发 dapp开发 链游开发 钱包开发 代币开发

一文彻底弄懂MySQL的MVCC多版本控制器

不在线第一只蜗牛

MySQL

CAE教程:HyperMesh概述与有限元分析简介

智造软件

仿真 hyperworks 有限元

从微信小程序原理来看app如何搭建专属的App小程序生态

Geek_2305a8

【CCE Autopilot专栏】资源成本降低60%,Serverless的省钱秘籍

华为云原生团队

云计算 容器 云原生

开源向量数据库性能对比: Milvus, Chroma, Qdrant

Zilliz

性能测试 Milvus 向量数据库 Chroma qdrant

数字身份管理建设是传统社会向数字社会演进的核心关键

芯盾时代

数字身份 身份安全

测试热招职位技能要求拆解公开课 — 开启你的软件测试进阶之路

测试人

软件测试

探索阿里巴巴中国站商品详情API返回值的多样性

技术冰糖葫芦

API Explorer API 文档 API 测试 API 性能测试

VMware Cloud Director 10.6 发布,新增功能概览

sysin

vmware Cloud Director

低代码平台助力医疗业实现业务优化与合规管理:全面提升运营效率

天津汇柏科技有限公司

低代码平台

选择让小程序在APP内运行的高性价比方案

Geek_2305a8

喜报!Bonree ONE荣膺GOITI首个“可观测性领域年度明星产品奖”

博睿数据

API自动化测试平台:企业API管理的得力助手

RestCloud

API接口 ipaas api自动化 api自动化测试平台

望繁信科技荣获2022年度创新产品与解决方案大奖

望繁信科技

数字化转型 流程挖掘 流程资产 流程智能 数字北极星

VMware Aria Operations 8.18 发布,新增功能概览

sysin

vmware aria Operations

按图搜索的智能化:拍立淘API返回值的算法解析

技术冰糖葫芦

API Explorer API 文档 API 测试 API 性能测试

拼多多商品详情数据接口使用方法

tbapi

拼多多商品详情接口 拼多多API

无需公网IP,贝锐花生壳内网穿透实现APP服务端API快速接入

贝锐

内网穿透 API 性能测试

租用海外云手机应注意些什么?

Ogcloud

云手机 云手机群控 云手机推荐 云手机养号 跨境电商运营

Swap丨DAPP开发:兑换交易所质押项目LP分红系统

区块链软件开发推广运营

交易所开发 dapp开发 链游开发 NFT开发 代币开发

智源发布原生多模态世界模型Emu3 实现图像、文本、视频大一统

智源研究院

网易轻舟云原生故障自动诊断系统实践_云原生_黄久远_InfoQ精选文章