背景 ​

区别于常规业务代码，rackmount作为供北向接口解析使用的配置文件，其在日志能力方面存在以下限制：

• 除plugin外的配置内容不具备日志能力
• 在plugin中添加日志与配置文件的轻量化定位不符，同时对问题定位的帮助有限

因此，对于在开发与维护过程中遇到的部分问题，需采用针对性策略进行定位。

使用调试日志进行定位 ​

openUBMC支持部分接口使用debug日志进行问题定界与定位，具体使用方法如下：

Redfish/web_backend 接口 ​

打开调试日志：

mdbctl
attack redfish
dloglevel debug

mdbctl
attack web_backend
dloglevel debug

CLI 接口 ​

使用debug级别日志进行接口访问：

ipmcget/ipmcset --verbose=debug

SNMP 接口 ​

目前 SNMP 接口不支持debug日志的能力。

SNMP 接口以节点为响应体，属性含义较为单一，使用场景较为简单，多数场景可通过分析 SNMP 接口与资源协作接口的关系定位问题。

典型日志 ​

接口访问开始/结束 ​

接口访问开始：Interface access begin, uri:%s, method:%s

接口访问结束：Interface access end, uri:%s, method:%s

若未找到上述日志，则表明映射器配置未加载，需要检查映射器配置格式问题。

此场景下的响应结果为404:ResourceMissingAtURI，CLI 接口回显为命令提示。

资源协作接口抛错 ​

部分错误由业务侧抛出：processing_flow_x, foreach_x, error_info:

映射器配置抛错 ​

部分 Statements 执行异常，此时调试日志中有(操作类型)+错误内容的日志，例如：

(Prefix-Add) The src data type is in correct, type = nil

校验拦截 ​

部分请求在校验阶段被拦截，未执行后续映射器处理，该场景下除接口访问开始/结束的日志外，仅有一条报错信息errs=错误内容。

使用一键收集中的资源协作接口信息进行定位 ​

openUBMC 一键收集中，AppDump 目录下，各组件目录均有 mdb_info.log，若通过映射器配置或其他定位手段推断出对应的资源协作接口（同时知道该接口的归属组件），可在对应组件的 mdb_info.log 中搜索该资源协作接口。

如下问题均可通过该方式定位：

• 组件启动失败，对应现象为一键收集结果中缺少该组件目录
• 资源协作接口初始化失败，对应现象为一键收集内，该组件的 mdb_info.log 中，没有预期的 path
• 资源协作接口属性不符合预期，对应现象为一键收集内，该组件的 mdb_info.log 中，接口对应的属性值不符合预期

此外，也可用使用该方法获取到的资源协作接口属性值逆向推导映射器配置错误。

修改响应体进行定位 ​

尽管映射器配置在多数场景下无法通过添加日志定位，但由于自身的特性，可以通过修改配置文件，将映射器配置中的具体处理流程输出至响应体进行定位。

例如，某接口的部分配置如下：

{
    "Resources": [
        {
            "Uri": "/redfish/v1/xxx",
            "Interfaces": [
                {
                    "Type": "GET",
                    "RspBody": {
                        "Name": "${Statements/GetName()}"
                    },
                    "Statements": {
                        "GetMetadata": {
                            "Input": "${ProcessingFlow[1]/Destination/Name}",
                            "Steps": [
                                "*" # *代表省略，下同
                            ]
                        }
                    },
                    "ProcessingFlow": [
                        {
                            "Type": "Method",
                            "Path": "*",
                            "Interface": "*",
                            "Name": "GetName",
                            "Params": [
                                "*"
                            ],
                            "Destination": {
                                "Name": "Name"
                            }
                        }
                    ]
                }
            ]
        }
    ]
}

修改 RspBody 为如下配置：

{
    "RspBody": {
        "Name": "${Statements/GetName()}",
        "TempName": "${ProcessingFlow[1]/Destination/Name}"
    }
}

修改后访问该接口，获取的响应体如下。据此可以推断是 Statements 处理过程中出现问题：

{
    "Name": null,
    "TempName": "Name"
}

常见问题 ​

Redfish/web_backend 接口响应超时 ​

一键收集后，查看3rdDump/access_log，若无法查询到超时的uri，则为传输层问题，例如环境问题或端口无法连接。

错误类型：502 ​

该错误通常出现在以下两种情况：

• openUBMC 已启动但北向接口服务未启动
• 请求中有不符合预期的格式，例如在非升级接口中，使用文件作为请求体

错误类型：412 ​

此错误类型一般出现在 Redfish 的PATCH方法中，可能的原因包括：

• 获取到 Etag 后，资源属性被修改
• 易变属性没有屏蔽，两次访问时易变属性值不同，导致 Etag 发生变化
• 响应体乱序：两次访问时响应体中有对象类型属性直接从资源协作接口获取，两次获取到的对象的key顺序不一致导致 Etag 发生变化
• 响应体乱序：Statements 中使用Lua table拼接响应体时，两次访问时拼接后的table key顺序不一致导致 Etag 发生变化

CLI 配置了接口，但执行命令时返回命令提示 ​

例如：配置了/cli/v1/user/list接口，但执行ipmcget -t user -d list却响应为-t参数的命令提示

Usage: ipmcget [-t target] -d dataitem [-v value]
    -t <target>
        ... ...

这种情况通常是由于缺少/cli/v1/user的配置，添加该配置即可。