排查基本原则

• HTTP类调用先使用postman或服务器curl命令调试成功，再用databus配置相同请求头和报文
• 涉及对接上下层的情况，要有排查问题的基本概念：比如A系统2024年9月2日19:04:35发了一个reqCode：188s00wASDE的报文(内含某个唯一字段)到databus，先检查databus执行日志中是否能搜索到这个唯一字段，再看databus什么时候发送给下层。

• 1、优先排查本文档，该文档是鉴于现场和技术支持基本不看在线文档的增补，后续有共性问题都会在该文档内增量维护。

  2、询问总部技术支持陈正兴

  3、总部技术支持排查不出来，由总部技术支持传达研发（日志、时间点、报文、现象）

• 中间件类的调用如Redis、MQTT都要优先保证服务器内能ping通对应ip和端口，再考虑对接，或者先用软件如Redis Desktop manager、mqtt.fx工具 调用成功保证对端服务正常，再考虑databus配置的问题。

常见问题清单

简单情况，不用查日志

1、 CMS消息发送异常，返回内容提示TimeCommunicateFail
表象：CMS消息发送异常，返回内容提示TimeCommunicateFail

根因： CMS调用databus超时时间太短，比如CMS请求databus 3秒超时， databus请求上层，上层5秒后给结果，此时databus把上层的结果返回给cms，由于cms已经请求超时结束 不会收到结果，导致cms再次重发。消息日志中显示该报错。

解决方式：cms配置超时时间。请求强保证：CMS请求databus超时时间A ms   > databus请求上层超时时间B ms    ，如cms请求databus 10000ms   > databus请求上层9500ms

2、数据流[1001]调用频率[>20/s]过高，限流拦截
表象：某系统调用DataBus接口后收到该报错，常见为cms或wms调用
解决方式：同一秒收到消息太多，配置系统参数23004，允许更多请求进入

3、数据流[1001]正在处理中，请稍后再试

表象：某系统调用DataBus接口后收到该报错，常见为cms调用

根因：完全相同的报文，A时间点CMS请求后，在A+x秒后再次发出请求，此时A的请求还在处理（一般为正在等待上层回复），就会针对B请求提示该错误。
解决方式：CMS（调用方）配置定时重发任务间隔和请求超时时间， 不要在上一个报文还没处理完下一个一样的报文又重发。正常系统也是等第一个请求失败才考虑重发，而不是第一个请求还在等又重发。

4、经过JSON构建节点后多个数据对象变为一个

表象：多个数据对象想构建数组，但是经过JSON构建后数组中只有一个元素

解决方式：

 排查①：最小数组路径结尾是否带#，正确的配置需要带#

排查②：是否配置了JSON解析—》映射规则（生成时间戳或reqCode）-》JSON构建  的情况，  应该把映射规则放在前面构建，如映射规则（生成时间戳，存到全局参数）—》JSON解析-》JSON构建（从全局参数中取时间戳）

排查③：是否把不一样的数据构建在非数组节点下，即②的根因。比如，orderNum：A   orderNum：B ，需要构建在/data数组节点下的/data/orderNum，配置却构建在/orderNum下。

排查④：每个数组节点下的/data/xx  默认值打个空格后删除，（将默认值由NULL变为空字符串）

5、模板[{\"code\":\"${codeh}\",\"message\":\"${messageMi}\"}\n]编译失败

表象：调用接口后报模板编译失败

解决方式：流程中有模板节点，配置不正确，一般为模板中的${param}参数在输入时为null导致，重新检查配置，调试配置。

6、connect timeout

表象：请求后报错connect timeout

根因：服务不连通或不存在该接口

解决方式：

①、先查服务器能否ping通客户ip端口

②、再查databus-服务配置中能否测试成功

③、最后查接口是否填写正确，通过postman先调用成功 再配置databus来交叉验证。

7、read timeout 

表象：请求后报错querytimeout

根因：对端服务返回结果太慢。

解决方式：

①：加大databus-服务配置中的请求接收超时时间。

②：对端服务优化执行效率

8、常见错误码：

3xx - 重定向

请求对端检查提供的接口URL是否正确

4xx－客户端错误

检查请求URL、方法、请求参数是否正确，先使用PostMan请求，一般为客户端问题，少数情况为构建的报文有问题导致调对端对端处理为4xx报错。

- 401 Access denied，请求尚未应用，因为它缺少目标资源的有效身份验证凭据。                  --确认是否有认证逻辑
- 403 禁止访问 (Forbidden) 服务器已理解请求，但拒绝实现请求。     --确认对端是否有接口
- 404 未找到 源服务器找不到目标资源的当前表示形式，或者不愿意透露存在该表示形式。   --确认接口是否配置正确，先postman调用成功，后databus配置
- 405 方法不允许。 源服务器知道请求线路中接收的方法，但目标资源不支持该方法。   --确认接口是否配置正确，先postman调用成功，后databus配置

5xx－服务端错误
检查请求参数是否正确，从日志中复制请求参数和URL，使用PostMan请求排查，一般为服务端问题。

- 500 内部服务器错误 服务器遇到意外情况，导致无法实现请求。                          --确认接口请求报文是否配置正确，先postman调用成功，后databus配置；还是报错让服务端排查
- 503 服务不可用 由于临时重载或计划内维护，服务器当前无法处理请求，这在一段时间延迟后可能会得到缓解。   --确认接口请求报文是否配置正确，先postman调用成功，后databus配置；还是报错让服务端排查

9、 第三方系统请求databus接口401错误码 或databus接口测试直接退出到登录页

根因：需要认证

解决方式：

1.2版本：在wms字典管理-白名单中加请求方ip白名单

2.0版本：

①：有wms在wms字典管理-白名单中加请求方ip白名单

②：没有wms在cms字典管理-白名单里加请求方ip白名单

10、databus只能https访问  （2.0版本）

根因：架构组新部署模式默认只开放https

解决方式：

运管-unify-ingress服务中开启HTTP访问

11、数据响应超时

根因：上层返回太慢

解决方式：

①：加大databus-服务配置中的请求接收超时时间。

②：对端服务优化执行效率

12、数据响应等待被取消

表象：某系统调用DataBus接口后收到该报错，常见为cms调用

根因：完全相同的报文，A时间点CMS请求后，在A+x秒后再次发出请求，此时A的请求还在处理（一般为正在等待上层回复），就会针对B请求提示该错误。
解决方式：CMS（调用方）配置定时重发任务间隔和请求超时时间， 不要在上一个报文还没处理完下一个一样的报文又重发。正常系统也是等第一个请求失败才考虑重发，而不是第一个请求还在等又重发。

13、databus1.2 后一个节点加载不到前面节点的参数

表象：某个节点选不到前面节点的输出

根因：A->C->B，AB节点之间经过映射规则C节点 或判断节点C，A节点新增参数后   B节点加载不到

解决方式：C节点编辑规则中新增一条记录后删除，保存即可刷新节点输出

14、databus 2.0版本 非application/json请求头无法访问databus自定义接口

根因：网关拦截

解决方式：升级网关https://filexc.hikvision.com.cn/hcs/services/FileShare/s?link=tkLXpk4G架构网关目录

15、databus2.0 请求cms、rtas、wms服务报401、405、无接口访问权限

根因：网关白名单拦截，内部服务互相的调用需要用域名。

解决方式：

1、databus中配置的rtas、cms、rcs服务用域名，域名是啥从运管-服务运维-网络拓扑里看。

2、改成域名后 像原本用/rcs/rtas/api/queryTask ip访问的接口路径都有改成   /api/queryTask，删除前面的/rcs /rtas，原因是一个ip访问有nginx做转发，域名访问是直接打到对应服务的。

16、无法建立WebSocket连接

根因：分为两种情况讨论 一、以前正常突然异常，说明上层服务出问题，服务器telnet ip port检查

二、首次配置 连接不上，说明ip、端口配错 或 服务器网络未打通

17、1.1 1.2版本点击调试没有反应。

现象：Console中能看出WebSocket报错

根因：使用9192访问，nginx 9192端口没有websocket转发配置。

解决方式：使用9191端口访问。

18、前面一个节点的输出，在后面节点输入选不到。

现象：

解决方式：

检查这两个节点之间，是否经过了映射规则节点或者分支节点，如果经过的话：

1、从头到尾针对这些节点，点击-> 新增一条规则 -> 删除新增的规则 -> 点击确定保存规则

2、再看后面的节点是否能选择

根因：

DataBus的参数是线性从头到尾传递，其中【映射规则、分支节点】会记录前一个节点的输出，并传递给下一个节点。

当A->【映射规则、分支节点】->C的链路配置完成后，重新修改A的参数，此时【映射规则、分支节点】没修改，所以导致C加载的参数不变。

因此需要修改中间的节点，保存下使得它重新加载前一个节点的输出。

19、SQL Server工具能连，DataBus连不了。

现象：

解决方式：

连接属性增加‌trustServerCertificate=true‌

20、databus HTTPS服务测试连接失败 

现象：服务器telnet提示unknown host

根因：

1、公网域名 由于海康服务器系统没DNS解析，导致服务器上databus无法连接，本地PC机能请求成功。按照解决方式1处理。

2、网络不通，导致服务器ping不通域名，PC主机postman也ping不通。按照解决方式2排查

解决方式：

1：databus主备机所在服务器执行

vim /etc/resolv.conf

文件尾追加两行

nameserver 114.114.114.114

nameserver 8.8.8.8

增加完服务器重新ping 域名

2、先postman检查通不通 （不通处理网络，通往下走）->  服务器ping 域名 / telnet 域名 端口  (不通处理网络，通往下走) -> DataBus服务测试

21、流程触发执行，执行日志没有记，日志中存在如下报错。

现象：

原因：接口触发中url配的过长，超过日志表记录长度

解决方式：

databus数据库des_msg_log 字段trigger_code 改成128

22、数据流内容过长无法保存

原因：内部程序长度限制

解决方案：

1、数据库des_data_flow中字段des_flow_content、des_flow_position改为text类型(注意长度中的数字要删除)
2、databus.properties中增加flow.size.limit=99999

复杂情况，根据执行日志中报错定位

1、DisruptorProducer send error

表象：

• 事件不触发流程
• websocket收到消息无法触发流程

解决方式：升级最新补丁包

2、存在发布接口调用[/xxx]日志，没有紧跟着的相同报文数据流开始执行日志

根因：项目业务量太大，超过databus默认的处理上限，导致databus能收到请求，但是不会立即触发执行数据流。

解决方式：

1.2版本

服务器tomcat.x/databus/WEB-INF/classes/applicationContext.xml 文件修改

<!--线程池配置 数据流执行专用 -->
<bean id ="flowTaskExecutor" class="org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor" >
<property name="corePoolSize" value="1000"/>
<property name="threadNamePrefix" value="flowExecutor-"/>
<property name="keepAliveSeconds" value ="300" />
<property name="maxPoolSize" value="2000"/>
<property name="queueCapacity" value="3000" />
<property name="rejectedExecutionHandler" >
<bean class="java.util.concurrent.ThreadPoolExecutor$AbortPolicy" />
</property>
</bean>

2.0版本 视现场业务量适当增大