外呼重呼排查

场景

今日下午出现被叫xxxx,4此拨打情况;对应的设置的是重呼2次;时间间隔30分钟.

SELECT id,caller,called,starttime,endtime,memberid,dropcause FROM cti_cdr WHERE starttime BETWEEN '2020-12-09 13:58:50' AND '2020-12-09 15:20:21' AND called = '13519211235';

结果:

排查

问题分析

重呼拨打可能出现的问题存在以下几点:

1. 应用系统重呼伦呼计算错误,导致往重呼表里面插入数据,进行多次外呼
2. 号码防火墙里面已经有一天只能拨打3此限制,对应的dropcause=180,如上图所示.
3. 外呼平台自身拨打原因:a.拨打数据不能从内存中删除 b.拨打数据从重呼表里面删除失败.导致下次继续拨打.

问题排查

1.查看重呼伦呼日志:

memberid=27287280

grep "27287280" repeatRoundLog.2020-12-09.*;

发现没有多次插入

2.查看重呼记录次数

SELECT * FROM ocm_buslist_calltimes WHERE list_id = 27287280;

发现也只有重呼过2次.

3.号码防火墙排查

查看cti_cdr的dropcause,发现第四次是180,说明号码防火墙起作用了.

4.外呼平台排查

以上发现应用系统没有问题,此时需要去排查外呼平台.

grep "ocm_buslist_timing" dbg_dbgnotify01_1607* | grep "delete" | grep "3097"

最终结论:
批次重启后批次线程对应的工作内存里面的数据处理没有及时释放;线程虽然销毁同时 呼叫已经发给fs了 但是可能 还没来得及删除重呼表里数据 此时开始拨打.

最终大都是发现在重启时候，出现了这种异常拨打情况

5、外呼重启批次重呼排查

有时候，外呼重启批次时候出现重新拨打情况:比如名单id:3444922;
我们查询数据库外呼操作：指令如下：

grep "3444922" dbg_dbgnotify01_1608622712.log;

这个时候进一步排查的话：看下日志有没停,如果没停就不会加载,使用以下命令查询：

grep “kill thread ACDERRCODE  notifyid” callxxxxx|grep 任务id

然后会出现以下信息:

update ocm_event set event_state=-1 where  event_id = xxxx