问题描述

当我们遇到第三方渠道消息接受不到情况，通过检查配置，分析消息日志均没有得出结论，或者客户要求我们出示调用第三方渠道接口成功的证据时，我们就需要通过日志来进行分析。

解决方法

• 1）根据提供的信息，确定发送人，大概发送的时间，然后在monitor中进行初步过滤

• 2）搜索关键字 MessageCenterServiceImpl--use sendMessage api 和 MessageCenterServiceImpl-- message save db，这块是业务方调用sendMessage接口的日志记录。寻找到匹配的记录，拿到对应的traceid，去掉关键字，时间和user过滤，根据traceid去分析。如果接口参数传递不对，会在校验的时候不过，这里的日志也就查询不到。

  

• 3）通过步骤2过滤，没有看到错误记录，并且查到了MessageCenterServiceImpl-- message publisher关键字，初步证明是发送到mq这一过程是没有问题了。

• 4）重复步骤1和2，这次关键字换成 messageId:和 send msg is ok。

  messageId: 这里就表明发mq已经分发到消费类中，然后找到对应的日志记录，拿到traceid，进行查询分析。

  send msg is ok：这里通常是表示消息已经发送成功了，如果是自己二开的渠道，需要看下是否在渠道解析类类里对部分错误有catch，额可以通过traceid过滤分析

• 5）各个渠道的日志关键字：

  dingding :  DingdingServiceHandler-- send msg info

  email:  邮件服务：创建消息ctx:

  短信：短信服务：发送消息:ctx:

  企业微信：send weixinqy message

  welink：send welink msg begine

  云之家-公众号消息：sendMessage--begine send, content=

  统一流程中心-发送到通知中心的消息：云之家发送消息到通知中心

  统一流程中心-传阅消息：body data is :

注意事项

• 日志分析如果找了一遍没有发现明显报错，可以提单找开发或者支持部的同学看一下，如果看到了明显的报错信息，可以直接贴到文档里，便于开发直接定位问题。

• 有开发经验的同学可以直接根据日志所提示的代码行数，反编译代码直接进行初步的分析

• 二开渠道如果不好定位问题，建议增加一些日志，便于分析。