在制作Ascend Device Plugin镜像时，会将故障频率及时长配置文件faultCustomization.json内置在镜像中，启动Ascend Device Plugin时会读取这两个文件的默认配置，作为当前故障处理依据。

如果用户想要自定义芯片故障频率及时长，可以在集群中创建ConfigMap文件（mindx-dl-fault-config）。

如果Ascend Device Plugin启动时，集群中已经存在mindx-dl-fault-config，Ascend Device Plugin会优先按照已存在的mindx-dl-fault-config中配置的内容，作为当前故障处理依据。
如果重新安装Ascend Device Plugin后，集群中已经存在mindx-dl-fault-config，Ascend Device Plugin的默认faultCustomization.json将不会生效，使用集群中已经存在mindx-dl-fault-config。若想要使用faultCustomization.json的默认配置，可以删除mindx-dl-fault-config，使Ascend Device Plugin读取默认faultCustomization.json文件。
如果ConfigMap文件内容存在格式错误等问题，Ascend Device Plugin会默认读取镜像中内置的ConfigMap文件的内容，作为当前故障处理依据。

操作步骤

以故障码80CB8002为例，如果某张芯片反复发生80CB8002故障，导致训练业务反复重调度，可以手动配置24小时内任务支持的断点续训最大次数为2，达到最大次数后故障的处理策略为ManuallySeparateNPU。

登录环境，进入Ascend Device Plugin解压目录。
执行以下命令，查询是否已经基于faultCode.json文件创建了mindx-dl-fault-config。
```
kubectl describe cm -n kube-system mindx-dl-fault-config
```
- 如果mindx-dl-fault-config已经存在，且存在faultCustomization.json的相关字段，执行步骤 4编辑该文件。
- 如果mindx-dl-fault-config已经存在，但是不存在faultCustomization.json的相关字段，需要先保存mindx-dl-fault-config内容，再删除mindx-dl-fault-config文件后，执行步骤 3创建该文件。
- 如果不存在mindx-dl-fault-config，执行步骤 3创建该文件。

执行以下命令，创建配置芯片故障频率及时长所需ConfigMap文件（mindx-dl-fault-config）。

kubectl create cm mindx-dl-fault-config -n kube-system --from-literal="PollInterval=300" --from-file=./faultCode.json --from-file=./faultCustomization.json

回显示例如下。

configmap/mindx-dl-fault-config created

表1 参数说明
参数名	是否必选	说明
mindx-dl-fault-config	是	动态配置故障码所需的ConfigMap文件名称，不能修改该文件名称。
kube-system	是	mindx-dl-fault-config所在命名空间，不能修改该命名空间名称。
PollInterval	否	不指定该参数则默认取值为300s。用于指定查询mindx-dl-fault-config文件是否更新的周期时间，单位为秒，取值范围为30~3600。PollInterval的修改将在下一个周期生效。
faultCode.json	是	用于保存故障码，必须与faultCode.json文件名称保持一致。
faultCustomization.json	否	用于自定义优雅容错时间、故障频率、故障持续时间（仅支持参数面网络故障）等配置，不指定该参数则没有故障频率配置，其余配置使用默认值进行处理。必须与faultCustomization.json文件名称保持一致。

执行以下命令，编辑mindx-dl-fault-config文件。

kubectl edit cm -n kube-system mindx-dl-fault-config

根据实际情况，修改芯片的故障频率和时长。

# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: v1
data:
PollInterval: "300"
# 修改芯片故障的故障级别
faultCode.json: |
{
"NotHandleFaultCodes":[
...
}
# 修改芯片故障的故障频率和时长
faultCustomization.json: |
{
  "GraceTolerance": {
    "WaitProcessReadCMTime": 30,
    "WaitDeviceResetTime": 150,
    "WaitFaultSelfHealingTime": 15
},
  "FaultFrequency": [
{
    "EventId": [
      "80C98000","80B78000","80B58000","80A18008","80A38008","80A58008","80B98000","80B98008","80BB8000",
      "80BB8008","80BD8000","80BD8008","80C78008","80C98008","80CB8008","80CD8008","80CF8008","80D98008",
      "80DF8008","80DE1801","80E01801","80E18008","80E38008","80E39200","80E3A202","80E3A203","80E78000",
      "80E78008","80F18000","80F18008","80F38008","80F78008","81318008","81338008","813B8008","81478008",
      "81578008","815F8008","81938008","81958008","81978008"
],
    "TimeWindow": 86400,
    "Times": 2,
    "FaultHandling": "ManuallySeparateNPU"
},
{
"EventId": ["80E18005"],
"TimeWindow": 86400,
"Times": 3,
"FaultHandling": "ManuallySeparateNPU"
}
],
  "FaultDuration": [
{
    "EventId": ["81078603"],
    "FaultTimeout": 20,
    "RecoverTimeout": 60,
    "FaultHandling": "PreSeparateNPU"
}
]
}
kind: ConfigMap
metadata:
creationTimestamp: "2024-06-20T10:12:07Z"
name: mindx-dl-fault-config
namespace: kube-system
resourceVersion: "52893696"
selfLink: /api/v1/namespaces/kube-system/configmaps/mindx-dl-fault-config
uid: bba9e17f-41dd-43b3-848e-3d29cb8c595a

在mindx-dl-fault-config文件中，在FaultFrequency字段下新增以下代码，设置0CB8002故障在24小时内任务支持的断点续训最大次数为2，达到最大次数后故障的处理策略为ManuallySeparateNPU。
```
{
  "EventId": ["0CB8002"],
  "TimeWindow": 86400,
  "Times": 2,      
  "FaultHandling": "ManuallySeparateNPU"
}
```
修改完成后，按“Esc”键，输入:wq!保存并退出。
等mindx-dl-fault-config文件更新生效（PollInterval取值，不指定则为300s）后，查看操作是否成功。
1. 执行以下命令，查询Ascend Device Plugin组件日志名称。
```
kubectl get pods -A | grep ascend-device-plugin
```
  回显示例如下：
  1
  kube-system ascend-device-plugin-daemonset-910-jmlf5 1/1 Running 0 6h34m
2. 通过查询到的组件日志名称，查询Ascend Device Plugin的组件日志信息。
```
kubectl logs -n kube-system ascend-device-plugin-daemonset-910-jmlf5
```
  - 若日志出现“load fault customization from configmap complete”，表示手动配置故障频率操作成功。
  - 若日志出现“modify xxx success”，表示ConfigMap中faultCustomization.json里的xxx参数设置成功。
  - 若日志出现“insert fault frequency success”，表示记录了一次频率故障发生时间，在频率窗口内，该卡的该故障记录次数达到频率故障触发次数以后，就会上报频率故障对应的故障级别。
（可选）手动恢复强制隔离的芯片。故障的处理策略为ManuallySeparateNPU时，故障恢复后该芯片也处于隔离状态，需要手动恢复强制隔离的芯片。
1. 执行以下命令，查找该节点的Ascend Device Plugin上报的device-info-cm。
```
kubectl get cm -n kube-system | grep deviceinfo | grep {nodeName}
```
2. 执行以下命令，编辑该device-info-cm。
```
kubectl edit cm -n kube-system {configMapName}
```
3. 将data下面的ManuallySeparateNPU后面已恢复健康的芯片名称删除。
```
apiVersion: v1
kind: ConfigMap
data:
  DeviceInfoCfg: '{"DeviceInfo":{"DeviceList":{"huawei.com/Ascend910":"Ascend910-1,Ascend910-2,Ascend910-3,Ascend910-4,Ascend910-5,Ascend910-6,Ascend910-7","huawei.com/Ascend910-Fault":"[]","huawei.com/Ascend910-NetworkUnhealthy":"","huawei.com/Ascend910-Unhealthy":""},"UpdateTime":1718702470},"CheckCode":"4f00cf1d220da26a8fdbeb5ba163a751d4b264c48b81d22149257e272ae3b413"}'
  ManuallySeparateNPU: Ascend910-0  
```
  删除ManuallySeparateNPU字段后所有芯片名称，并将取值设置为空“”。
4. 修改完成后，按“Esc”键，输入:wq!保存并退出。
5. 等待1个上报周期（若设备信息有变化，那么在健康状态检查周期内就会上报，如果设备信息没有变化，那么上报周期固定为5分钟）后，执行以下命令，查看device-info-cm中ManuallySeparateNPU是否存在刚才删除的芯片名称。若不存在，则芯片恢复健康成功，可继续正常使用该芯片。
```
kubectl describe cm -n kube-system {configMapName}
```

（可选）配置芯片故障频率及时长

操作步骤