Redfish接口常见错误码 ​

Redfish是基于RESTful协议实现的可扩展平台管理的应用程序接口，接口响应码沿用通用RESTful协议的规范。当redfish接口发生错误时，我们优先通过接口返回的响应码进行问题定位分析。 常见的响应码有哪些？

如何查看接口响应码？ 方法1：查看客户端响应消息（以Postman为例） 方法2：查看服务端nginx日志 BMC使用nginx作为反向代理服务器，BMC处理的任何redfish请求后，nginx都会记录access日志。

• access日志路径： 一键收集中的access日志路径：3rdDump/access_log BMC环境上的access日志路径：/dev/shm/log/web/access_log 此外，error日志也是nginx的重要日志，记录着nginx内部错误的信息。
• error日志路径 一键收集中的error日志路径：3rdDump/error_log BMC环境上的error日志路径：/dev/shm/log/web/error_log

Redfish接口错误定位方法 ​

Redfish接口的错误分为客户端错误和服务端错误两大类型。如果发生客户端错误，通常都是因为使用方式不正确，优先排查请求参数是否正确。如果发生服务端错误，请联系组件owner进行问题定位。

客户端错误 ​

4xx错误表示客户端发送的请求有语法错误（请求头，请求参数等），服务器无法处理。

400响应码 ​

1. 接口返回400响应码表示请求非法，客户端侧输入异常错误。此错误码是服务端根据输入信息返回符合程序预期的报错结果，一般原因是客户端传入了错误的请求参数。 （例如：传入了错误类型参数，传入了非法的文件路径……）

401响应码 ​

接口返回401响应码表示无效的用户请求，一般是由用户名密码校验错误（Basic Auth登录场景）或Token校验（会话登录场景）错误导致的。

403错误码 ​

接口返回403响应码表示用户权限不足，一般是因为用户访问的接口所需的权限不在本用户具有的权限范围内。 （例如：普通权限用户访问了需要常规设置权限的接口）

404错误码 ​

404错误表示访问请求资源不存在。一般是因为客户端访问了服务器不存在的URI资源。

405错误码 ​

405错误表示不支持的操作类型。一般是因为服务器不支持客户端指定的请求类型。 （例如，客户端发送了DELETE请求到https://device_ip/redfish/v1/Managers/1，而此接口不支持DELETE方法）

412错误码 ​

412错误表示前提条件失败。通常在进行PATCH请求时，如果请求头中包含If-Match的与服务器资源的ETag不匹配，则会返回412错误。

概率性412问题： 当响应体中的属性存在抖动时，会导致自动化用例概率性出现412错误。如 /redfish/v1/Managers/:managerid 接口的属性 LastResetTime。 定位抖动属性的方法：使用脚本反复执行PATCH方法，出现错误则打印前后的响应体及对应的etag值，对比确认异常属性。 修改方案：在IgnoreEtags中添加会抖动的属性

499错误码 ​

499错误是nginx自定义的错误码，并不是http标准的错误码。一般是因为客户端在nginx完成响应之前就提前断开了连接。该问题可能的原因

• 在BMC处理redfish请求过程中，服务端未返回响应数据，客户端主动把连接断开。
• 客户端与BMC之间的网络连接状态不佳，在BMC返回响应数据之前就tcp连接中断。
• redfish组件从资源树获取资源属性超时，响应时间超过30s。由于部分测试脚本设置的超时时间为30s，超过时间限制后就会提前断开连接。该场景下需要进一步定位获取资源属性超时的原因。

注意：由于客户端与nginx之间的连接已经断开了，所以客户端无法接收到499的错误码，499错误码仅在nginx的access日志上记录。

服务端错误 ​

5xx服务端错误是指服务器在处理请求时发生了错误，无法完成请求。这种错误通常是服务器出现了故障或者负载过大导致的，需要管理员进行排查和修复。

500错误码 ​

500错误码表示BMC服务端内部错误。一般是因为BMC在处理请求时发生了在程序预期之外的错误。具体原因需要通过debug日志进行定位。当前已知的问题场景：

1. 业务组件在抛错误的时候使用了错误Id，未被正常识别，错误引擎将其统一转换成内部错误。 定位方法：查看/var/log/app.log,有如下打印。

2. 业务组件处理请求时发生异常导致程序中断。如果不是程序主动抛出InternalError，接口相关的组件必然会打印ERROR级别日志，记录详细的报错信息。 案例分析：挂载32次虚拟媒体后，第33次挂载虚拟媒体概率性报500 此问题出现原因为/redfish/v1/TaskService/Tasks/:taskid接口在查询task进度时从资源树获取到任务执行结束时间为空字符串，而接口处理逻辑未考虑此异常场景，在对时间进行格式转换时执行报错，程序异常退出。 定位方法：查看/var/log/app.log，在redfish接口响应的时间点，对应业务组件存在相应的ERROR日志，并指示报错的代码行。

3. 打开连接数过多。 如果nginx打开的连接数量过多，超过了上限，新接收的请求会直接返回500错误码。 定位方法：查看nginx的error日志，在redfish接口响应的时间点，有如下报错信息 案例分析： host_agent遍历资源创建了大量的HTTP请求占用了资源，影响访问其他redfish接口（报500） 此问题的原因为host_agent组件在特殊条件下创建大量http请求，且失败。占用过多连接资源。导致其他redfish接口访问直接报500

502错误码 ​

502错误表示网关连接错误。

前置知识 ​

首先介绍一下redfish接口的处理流程，整个流程的主体主要有3个，分别是客户端（client），代理网关（nginx）和redfish服务（backend）。当客户端发起redfish请求时，客户端先与代理建立一个tcp连接，两者之间通过这个连接进行数据传输。代理接收到客户端的请求后，向redfish服务申请创建一个tcp连接，代理与服务端之间通过这个连接进行请求数据传输。 接口返回502响应码时，一般是因为nginx与redfish服务之间的tcp连接异常，具体原因可以通过nginx的error日志进行定位。当前已知的问题场景：

1. redfish服务挂了 1.1 场景一：访问redfish接口时，如果redfish服务已经挂了，nginx与redfish建立连接会失败。 定位方法：nginx的error日志有如下错误记录 1.2 场景二：redfish在处理请求时，此时如果redfish服务突然挂了，nginx会立即返回502错误。 定位方法：该场景下，nginx的error日志记录upstream prematurely closed connection while reading response header from upstream。 该问题场景需要进一步排查redfish服务异常原因。该问题多发于自动化测试中访问redfish接口时BMC被重启，导致redfish服务shutdown。 查看操作日志，检查redfish返回502的时间点附近是否有BMC重启记录（固件升级和maca健康检查等都有可能触发重启）

2. redfish服务卡住 当nginx与redfish服务之间建立tcp连接后，就可以传输数据，当nginx读取数据超过15分钟时，连接会超时断开并返回502错误码。 定位方法：查看error日志，有upstream timed out (110: Connection timed out) while reading response header from upstream 案例分析： xx.xx.xx.xx环境重启后，redfish访问超时， web页面加载空白 redfish最多能支持并发处理4个请求。如果前面有超过4个请求都访问超时。后面的请求就需要一直等待，当等待的时间超过15分钟时，nginx就会断开连接，直接返回502。

3. nginx与redfish建立tcp连接失败 问题现象为nginx在向redfish建立连接过程中，由于连接超时建立连接失败。 定位方法：查看error日志，有110错误码：Connecton timed out 案例分析：偶发出现redfish接口返回502 该问题原因为BMC系统时钟异常，时间跳变导致nginx调用connect系统调用函数超时。 解决方法：配置NTP服务器

504错误码 ​

To be Continue ……