微组件管理功能由MACA（micro & agile component architecture）组件提供，本文将介绍组件状态检查、系统重启机制等微组件管理功能以及相关的阈值配置，帮助开发者分析和定位组件、BMC重启问题

1 组件状态检查

1.1 启动状态检查

1.1.1 检查范围

service.json中配置了type和deployConfig字段的组件 type字段：用于表示组件类型，常驻进程组件需要配置type为application deployConfig字段: 用于表示拉起组件的systemd配置文件，组件按照子系统维度拉起，如framework.service拉起hwdiscovery

1.1.2 检查原理

每个组件的默认启动状态会被置为starting，框架对公共接口 bmc.kepler.MicroComponent 上树时，会把该接口下的Status属性置为Starting 在组件初始化完成后，会把启动状态置为 InitCompleted 如果在一个组件的六次启动状态检测中，组件的启动状态始终为starting，就会被认为组件启动失败

1.1.3 检查机制

MACA 在启动1分钟后会进行两轮启动状态检查，每轮检查时间为2分钟
第一轮检查时，每个组件最多检查8次，每次间隔15秒，八次都失败后，重启检查失败组件所在的子系统进程，将组件服务重新拉起
重拉子系统进程后会进行第二轮检查，如果第二轮检查再次失败，则重启BMC。由于启动状态检查成功之后才会通知m3，升级BMC后连续启动检查失败2次后切换分区，连续10次检查失败后不再复位BMC
升级之后，启动状态检查失败，导致连续重启BMC 2次，会触发切分区机制；非升级场景（如修改代码调试导致重启后启动状态检查失败），连续重启BMC 3次，会触发切分区机制；无论哪种场景，切分区都只会切一次

1.1.4 阈值配置

在manifest仓的mc_control.json中，可以实现对启动状态检查各参数阈值的配置

json

"startup_check": {
    "enabled": true,
    "timeout_mins": 2,
    "recovery_condition": {
        "abnormal_threshold": 2
    },
    "recovery_policy": {
        "action": "restart_system",
        "threshold": 10
    }
}

参数说明如下 enabled：启动状态检查开关，可配置为true或false，默认为true timeout_mins：每轮检查的超时时间阈值，单位为分钟，默认为2 abnormal_threshold：最大检查轮数，默认为2 threshold：检查失败后BMC重启次数上限，默认为10

1.2 健康状态检查

1.2.1 检查机制

当组件启动后，会在资源树上注册健康状态检查的方法（框架提供的微组件框架自带接口和方法）
MACA收集到所有组件列表后，需要周期性调用该方法检测组件的健康状态，如果健康状态异常达到阈值（检测周期1分钟，连续3次，框架主程序需要杀掉对应的组件所在的进程，由systemd重新拉起）

1.2.2 阈值配置

在manifest仓的mc_control.json中，可以实现对健康状态检查各参数阈值的配置

json

"health_check": {
    "enabled": true,
    "interval_mins": 1,
    "recovery_condition": {
        "abnormal_threshold": 3
    },
    "recovery_policy": {
        "action": "restart_process",
    }
}

参数说明如下 enabled：健康状态检查开关，可配置为true或false，默认为true interval_mins：检测周期，单位为分钟，默认为1 abnormal_threshold：健康状态异常阈值，默认为3

1.3 组件在线状态检查

组件运行阶段出现异常导致组件（组件所在进程）连续重启，通过组件健康状态检查无法对齐采取自愈措施时，需要新增检查机制，进行干预。例如，某组件执行到特定业务时出现异常，导致进程反复coredump，由于组件能正常启动，且在健康状态检查的周期内，MACA能收到健康状态OK的返回消息

1.3.1 检查机制

组件在10分钟内连续掉线5次，则复位BMC
组件下线总次数：所有组件累计下线2000次后复位BMC
默认最多复位3次，超过3次不再复位，只记录组件掉线次数

1.3.2 阈值配置

在manifest仓的mc_control.json中，可以实现对组件在线状态检查各参数阈值的配置

json

"online_check": {
    "enabled": true,
    "recovery_condition": {
        "time_window_mins": 10,
        "abnormal_threshold": 5
    },
    "recovery_policy": {
        "action": "restart_system",
        "threshold": 3
    }
}

参数说明如下 enabled：组件在线状态检查开关，可配置为true或false，默认为true time_window_mins：检测时间范围，单位为分钟，默认为10 abnormal_threshold：连续掉线次数阈值，默认为5 threshold：复位次数阈值，默认为3

2 复位管理

MACA提供了BMC平滑重启、强制重启机制

2.1 平滑重启

2.1.1 看门狗概念

看门狗（watchdog）：watchdog可以理解为一个定时器，一种硬件设备，定时器超时会触发某种动作，如重启系统。每秒给watchdog发送一个“保持活动”的信号，表示BMC正常运行。在Linux内核中，可以通过ioctl命令来控制watchdog定时器的行为。

平滑重启会在完成准备以及清理阶段后，停止看门狗喂狗，复位BMC

2.1.2 复位流程

当前平滑复位流程共有Prepare、Process、Action、Cancel四种阶段，libmc4lua在mc.mdb.micro_component.reboot库提供on_prepare、on_process、on_action、on_cancel方法供业务注册自定义处理，各阶段的说明如下

阶段	说明	超时限制	组件操作约束	执行条件	执行成功的后置处理	执行失败的后置处理	注意事项
Prepare	复位前准备阶段	10s	组件进行复位前准备操作，要求操作耗时短、可恢复，例如检测是否可以进行复位、数据落盘	组件正常运行，且未执行复位处理	进入Process	进入Cancel阶段	所有组件Prepare成功后，BMC必定会完成复位操作
Process	复位前处理阶段	默认120s，支持可配置，上限为600s，下限为120s	组件进行复位前处理操作，支持耗时较长、不可回滚、依赖其它组件的处理操作，例如CPLD生效。该阶段操作不能影响组件业务功能的正常运行	所有组件复位前准备完成，且组件正常运行	进入Action阶段	进入Action阶段	返回结果不影响后续操作和BMC复位
Action	复位执行阶段	60s	组件进行复位执行操作，支持耗时适中、不可回滚、不依赖其它组件的操作，例如资源回收、停止服务、数据落盘	组件正常运行	执行重启	执行重启	1. 返回结果不影响BMC复位 2. 执行完成后，组件业务可能停止工作
Cancel	复位取消阶段	无	组件进行复位取消操作，恢复Prepare阶段的操作，并取消重启	组件正常运行	取消复位	取消复位	无

注意事项：各复位操作接口的使用需要符合上述约束，错误实现复位时操作或不实现复位时操作可能引发业务错误。尤其注意到进入Action阶段后，当前组件依赖的其它组件可能已停止正常工作，此时组件应该停止关键业务的执行，避免引发误告警等问题

2.2 强制重启

直接停止喂狗，复位BMC。MACA在组件启动状态检查失败、触发组件连续掉线机制重启时，会执行强制重启

1 组件状态检查 ​

1.1 启动状态检查 ​

1.1.1 检查范围 ​

1.1.2 检查原理 ​

1.1.3 检查机制 ​

1.1.4 阈值配置 ​

1.2 健康状态检查 ​

1.2.1 检查机制 ​

1.2.2 阈值配置 ​

1.3 组件在线状态检查 ​

1.3.1 检查机制 ​

1.3.2 阈值配置 ​

2 复位管理 ​

2.1 平滑重启 ​

2.1.1 看门狗概念 ​

2.1.2 复位流程 ​

2.2 强制重启 ​

1 组件状态检查

1.1 启动状态检查

1.1.1 检查范围

1.1.2 检查原理

1.1.3 检查机制

1.1.4 阈值配置

1.2 健康状态检查

1.2.1 检查机制

1.2.2 阈值配置

1.3 组件在线状态检查

1.3.1 检查机制

1.3.2 阈值配置

2 复位管理

2.1 平滑重启

2.1.1 看门狗概念

2.1.2 复位流程

2.2 强制重启