v6关键的典型问题排查流程---王剑鑫

1、 内部公开 Internal Use OnlyV6 关键的典型问题排查流程1数据拥塞&丢失问题数据拥塞&丢失问题的排查总体方向是从后往前排查(从数据库入库开始向前端排查)，前端的的数据拥塞&丢失可能是后端的数据拥塞&丢失导致的。(1)检查数据库服务器入库是否有堵塞：a.先查看数据是否有异常，通过 iqproxy_assit.log 里面的 ERROR 可以看到，请先查看环境变量、sybase 接口配置等问题；时隔 5 分钟多次使用 df k 命令查看磁盘剩余空间是否持续在增长，如果持续在增长说明数据有堵塞；另一种验证方式是用 select max(etime) from dr_xxx、sele

2、ct max(sttime) from st_xxx 看cdr 和统计结果最新的入库时间和当前时间的偏差；排查网卡是否错误设置为百兆网卡（要求为千兆）；排查网络带宽不够的问题，可使用 ftp 工具进行验证真实的带宽，如果带宽确实不够，需要协调用户解决带宽资源；排查网络不稳定的问题，网络本身存在丢包、抖动、阻塞等情况，需要协调用户解决网络问题。另外，在有些地方还发现，对于使用内外网两套地址段的情况，如果都直接使用映射的外网地址段可能导致网络不稳定的情况；使用 iostat 命令查看磁盘 io 是否过于繁忙。如果 io 过于繁忙而发生堵塞：b.c.d.e.f.i)首先按照配置指导书的模型查看内存和

3、磁阵的配置是否满足要求，并实地测试磁阵的 io 性能，如果服务器内存&io 不满足要求，需要进行分流-按地市进行分流；如果服务器的内存&io 满足配置模型的要求还堵塞，可以考虑调优iqproxy.ini 的参数。可以增加 MAXFILE 到 300，MINLOADSIZE 到 5M 或者 10M 的数值，MAXLOADINTERV 调整到 600 或者 1200，这些调整目的都是尽量让入库文件集中入库，避免过多的小文件入库。如果调整还是不行，最后一招就是 1 分钟的统计结果不入库，当然这个要看以前用户有没有查询 1 分钟统计粒度的要求(一般都没有)。ii)g.如果 io 占用不大还堵塞：i)首

4、先按照配置指导书的模型查看服务器的 CPU 核数及其主频是否满足要求，如果不满足，只能加 CPU 或者分流-按地市进行分流；如果服务器的 CPU 核数及其主频满足要求还堵塞，可以尝试调优iqproxy.ini 的参数，将 POOLSIZE 的数值提高，先提高到及其核数/4， 然后逐步调高。这个会提升入库效率，但同时也会导致 IO 占用增大最终影响查询性能，所以有一个临界点需要现场总体上自行把握。ii)h.排查时间同步是否有问题，对于有 2046 年之类这样的数据将极大影响入库的性能；(2)检查 NSR 服务器是否有拥塞；a.首先排除NSR 服务器上的cdrdispatch 有没有发送失败的情况

5、（注意这里说 NSR 服务器并不仅仅指nsr 程序本身，而是包括其相关的cdrdispatch，后面的NSR_EX、 BcpDataFile 等都是一样，不再说明这一点），如果有发送失败一般是 NSR 处理 不过来或者是后端模块(比如 kpidatasvr 或对外接口或入库程序)堵塞注意 All Rights reserved, No Spreading abroad without Permission of ZTE 第1页 内部公开 Internal Use Onlykpidatasvr 的 pipeline_kpidata.xml 里面 FiltrateFlag 要设置为 1，否则 kp

6、idatasvr内存很快占满进而拥塞向前传递；使用 nsrtask，输入 nsr 的服务器地址及 6008 端口，查看低优先级的 1min 粒度的统计是否能在 50s 以下处理完成，以及最新正在处理的低优先级的 1min 粒度的是否接近当前时间(延迟 3 分钟以下可认为正常)；排查网卡是否错误设置为百兆网卡（要求为千兆）；排查网络带宽不够的问题，可使用 ftp 工具进行验证真实的带宽，如果带宽确实不够，需要协调用户解决带宽资源；排查网络不稳定的问题，网络本身存在丢包、抖动、阻塞等情况，需要协调用户解决网络问题。另外，在有些地方还发现，对于使用内外网两套地址段的情况，如果都直接使用映射的外网地址

7、段可能导致网络不稳定的情况；排查数据流有无环路，有环路时会出现一个 cdr 多次入库的情况； 查看 cpu 核数和主频是否满足配置指导书要求；查看内存是否不足，可用 free 命令看(top 里的 free 并不是全部的物理内存的剩余值)，同时看看 vmstat 5 命令看是否有大量的内存页和磁盘交换。如果内存不足，需要补充内存；排查时间同步是否有问题，对于有 2046 年之类这样的数据将极大影响 nsr 的性能；如果 nsr 处理不过来，一般要进行分流处理按地市进行分流。如果某台服务器的 CPU、内存、IO 资源还剩下很多，可考虑一台机器上部署两个 nsr,并使用nsrtask 查看处理效率

8、是否有提升(启动多个nsr 时需要将nsr 的监控端口改一下，否则只能使用 nsrtask 查看其中一个 nsr 的处理效果)。b.c.d.e.f.g.h.i.j.(3)检查 NSR_EX 服务器是否有拥塞；除 nsrtask 填写的端是 6009 之外，其他同 NSR。需要注意的是 NSR_EX 各个专题运行时间如果没有错开，可能会导致忙时的固定时段的拥塞(cdrdispatch 向 NSR_EX 发送失败，这段时段内可以看到 io 的等待时间占用比例较大)，目前版本中 prestatsvr_ex.xml 的寻呼黑洞(id=backHole_60MIN)和单通等 (id=dll_60MIN)

9、默认的运行时段相同，需要分别将其 delay 调整到 20 和 30。检查 BcpDataFile 服务器是否有拥塞：(4)a.首先排除 BcpDataFile 服务器上的 cdrdispatch 有没有发送失败的情况，如果有发送失败一般是数据库服务器堵塞；查看 bcp_assist.log 里面有无 ERROR 异常，如有请先查看环境变量、sybase 接口配置等问题；排查 BcpDataFile.ini 里面 IP 是不是设置的服务器的具体 IP 地址，而不要用；尽量不要多个 NSR 对应一个 BcpDataFile 入库，否则可能导致有时会出现频繁地表切换；排查网卡是否

10、错误设置为百兆网卡（要求为千兆）；排查网络带宽不够的问题，可使用 ftp 工具进行验证真实的带宽，如果带宽确实不够，需要协调用户解决带宽资源；排查网络不稳定的问题，网络本身存在丢包、抖动、阻塞等情况，需要协调用户解决网络问题。另外，在有些地方还发现，对于使用内外网两套地址段的情况，如果都直接使用映射的外网地址段可能导致网络不稳定的情况；排查数据流有无环路，有环路时会出现一个 cdr 多次入库的情况；b.c.d.e.f.g.h. All Rights reserved, No Spreading abroad without Permission of ZTE 第2页 内部公开 Internal

11、 Use Only(5)检查大关联回填服务器是否有拥塞；a.首先排除大关联服务器上的 cdrdispatch 有没有发送失败的情况，如果有发送失败一般是大关联程序处理不过来或者内存不足；b.查看 assocsvr_assist.log 里面有无 ERROR 异常，如有请先查看环境变量、sybase 接口配置等问题；排查网卡是否错误设置为百兆网卡（要求为千兆）；排查assocsvr.xml 里的BufferCacheAdapter 下面MaxSize 是否已经设置为物理内存的 80%；c.d.(6)检查协议处理机是否有拥塞。a.b.排查网卡是否错误设置为百兆网卡（要求为千兆）；排查网络带宽不够的

12、问题，可使用 ftp 工具进行验证真实的带宽，如果带宽确实不够，需要协调用户解决带宽资源；排查网络不稳定的问题，网络本身存在丢包、抖动、阻塞等情况，需要协调用户解决网络问题。另外，在有些地方还发现，对于使用内外网两套地址段的情况，如果都直接使用映射的外网地址段可能导致网络不稳定的情况；如果是 packetcollector 接收数据查看 packetcollector 有无lost data 1000 times 的日志，如果是信令网关接收数据，查看信令网关日志有无大量 send data fail 日志刷屏 如果有一般是 merge 或其后端的模块处理不过来而堵塞；查看各级 stage 的数

13、值是否持续增大，如果不为 0 且持续增大说明有堵塞(增长到 25 万以上一般就堵死了)；堵塞时先判断数据流入量是否超出了配置模型的要求，并检查 CPU 的核数和主频、内存是否足够(指导书上对内存有偏差，实际对于 8 核 2.0G 以上的 Interl 的 CPU，Mc 口情况下，8G 内存可以处理 40-50Mbps，16G 内存可以处理80-100Mbps)。鉴于目前默认提供协议处理过多，如果现场以默认配置跑程序的话，top 命令显示 8 个cpu 的可能会处理不过来导致堵塞Infortransform 日志中有大量的sendxdr fail 日志，后方 cdrdispath 堵塞或者断连；

14、Merge 中大量 send fail 日志，后方流量统计 cdrdispath 堵塞或者断连，c.d.e.f.g.2(1)统计和详单对不上的问题当天的统计和详单有可能是对不上的，特别是离查询时间较近的时间段，因为有一些统计或详单还没有入库或者还没有补算。先查看前一天的记录看是否存在该问题。(2)检查大关联以后的各流程的 cdrdispatch 的日志中有无发送失败信息，如有发送失败信息将会导致统计和详单对不上。发送失败的原因有：a.网络带宽不够，可使用 ftp 工具进行验证真实的带宽，如果带宽确实不够，需要协调用户解决带宽资源；网络不稳定，网络本身存在丢包、抖动、阻塞等情况，需要协调用户解决

15、网络问题。另外，在有些地方还发现，对于使用内外网两套地址段的情况，如果都直接使用映射的外网地址段可能导致网络不稳定的情况；后端模块处理不过来而导致的拥塞，参见”数据拥塞&丢失问题”的处理。b.c.(3)检查 bcp_assist.log(各个部署了 BcpDataFile 的设备)是否有失败的日志，如果有需要根据日志的具体情况进行处理，直至解决失败情况；检查 iqproxy_assist.log 是否有入库失败的日志，如果有需要根据日志的具体情况进行处(4) All Rights reserved, No Spreading abroad without Permission of ZTE 第

16、3页 内部公开 Internal Use Only理，直至解决入库失败情况；检查BcpDataFile(NSR 和NSR_EX 和TDR 相关的)里的OVERDUETIME 是否设置为 0， 否则有一些超期的数据不入库会导致统计和详单对不上；检查配置有无重复情况，比如网元或者小区有重复时，查询出来的详单可能会有重复的记录，而导致统计和详单对不上；其他问题可以认为是版本有问题。(5)(6)(7)3(1)号码回填率低的问题确认各个 MscServer 周围的链路是否都采集完整，如果不完整需要确保链路采集完整。如确实无法保证所有 MscServer 周围的链路采集完整，那就仅对保证采集完整链路的Ms

17、cServer 的产生的 XDR 检查其号码回填率是否正常；检查分流方案是否正确：如果有分流(多个关联服务器)，需要确保每个 MscServer 周围的各个链路(IP&E1)都要分到同一台关联服务器上， Mc 口/网间可根据协议处理机分、MAP/CAP 可根据信令点码分，建议按照地市为粒度进行分流；检查服务器资源是否足够：在 2000 万并发用户(包括主被叫和外省参与用户)或者100Mbps 的CDR 时需要 32G 以上内存，并使用 2.4GHz 以上的主频；(2)(3)(4)通过的时间同步 KPI 报表、单板基本信息分别检查各个协议处理机&大关联回填服务器、板卡的时间同步是否都正常（需要确

18、保时间同步的时间源都指向同一个时间源，并部署 monitor 程序以保证数据能够正常上报给），如果不正常，一方面会影响协议处理机合成本身，另一方面对号码回填关联也有很大影响；检查各个协议处理机有无丢包、乱序、处理不过来的现象，可通过日志分析，具体操作方法参考版本中的调测手册；检查各个协议处理机的 CDR 合成率，具体操作方法参考版本中的调测手册，需要保证在 99%以上；检查协议处理机送过来的实时cdr和完整cdr数据是否一致和无较大时延。具体方法是： 使用ztp_client_r工具判断一下各个协议处理机过来的完整cdr和实时cdr的数据是否基本一致、延时是否都在正常范围(BSSAP应该80%

19、以上都在5分钟之内，BICC&MAP等应绝大部分在1分钟之内)；协议名称 完整CDR命令字 实时CDR命令字(5)(6)(7)BSSAP BICC MAPCAP1700117002170061701221800218012180221803(8)(9)检查关联服务器 assocsvr 日志有无错误信息，具体操作方法参考版本中的调测手册；(10) 登录 web 地址：http:/关联服务器:8090，查看页面里 group_initial_call 的 overdue_count 与 in_count 的比例应不大于 10%，如果不是，说明时间同步有问题或者合成等模块导致的迟滞；(11) 登录

20、web 地址：http:/关联服务器:8090，查看页面里各个 Stage 的 queue 的 CURRENT(第一列数值)是否趋向于 0,如果不是说明处理不过来；(12) 检查所在运营商的漫游号码前缀是否和 assocsvr.ini 里 msrn_prefix 配置得一致；(13) 检查assocsvr.xml 里BufferCacheAdapter 的MaxSize 值是否合理(推荐是物理内存的 80%)。 All Rights reserved, No Spreading abroad without Permission of ZTE 第4页 内部公开 Internal Use Onl

21、y4(1)(2)查询性能慢的问题确保数据库的 CPU 及磁盘 io 能力满足要求，具体参见配置指导模型；对于磁阵 io 性能低得地方，关闭 1 分钟的统计入库，并加大入库缓存时间（尽量集中入库节省 io）；检查相应的索引是否正确建立：检查每天的建索引调度是否正常运行。如果 xdr 查询慢， 重点检查一下各个协议的主被叫号码有没有建立逆向字段索引(使用 sp_iqindex 表名查看索引实际建立结果)；如果是详单慢，重点检查 etime 字段以及使用 F9 命令显示出来的查询的条件是否有相关索引；检查磁盘 io 是否过于繁忙，如果过于繁忙，将会导致查询时得不到响应的资源，最终响应很慢。如果硬件配

22、置满足配置指导书的要求还繁忙，可以考虑调优 iqproxy.ini 的参数。可以增加MAXFILE 到300，MINLOADSIZE 到5M 或者10M 的数值，MAXLOADINTERV调整到 600 或者 1200，这些调整目的都是尽量让入库文件集中入库，避免过多的小文件入库。如果调整还是不行，最后一招就是 1 分钟的统计结果不入库，当然这个要看以前用户有没有查询 1 分钟统计粒度的要求(一般都没有)。CDR 合成不完整问题检查各协议处理机处理的数据流量是否超出了配置模型的要求，并检查 CPU 的核数和主频、内存是否足够(指导书上对内存有偏差，实际对于 8 核 2.0G 以上的 Inter

23、l 的 CPU， Mc 口情况下，8G 内存可以处理 40-50Mbps，16G 内存可以处理 80-100Mbps)；使用 E1 链路丢包率排查链路是否丢包；(3)(4)5(1)(2)(3)通过的时间同步 KPI 报表、单板基本信息分别检查各个协议处理机、板卡的时间同步是否都正常（需要确保时间同步的时间源都指向同一个时间源，并部署 monitor 程序以保证数据能够正常上报给）；(4)排查协议处理机是否有节点数不够、发送失败的日志信息、协议处理机是否有合成堵塞的日志信息；merge 上是否有lost data 1000times 的日志，packtclector 上是否有丢包日志，信令网关上

24、是否有发送失败日志。(5)(6)检查协议处理机上的组是否配置正确；检查 2M/4M 板采集的链路是否直接使用信令网关的方式发数据给协议处理机，解决UDP 发送发送数据丢失的问题；能够用 EGF4 做信令网关的尽量用 EGF4 信令网关merge 与 packtclector 或者信令网关对接问题Merge 与 Packtclector 对接：需要注意这种共享内存方式来接收数据的模式，要求 merge(7)6与 packtclector 的配置中内存大小和内存块数目要一致，在 dp10 发布的版本中默认的配置都是 10M*5；如果不一致会导致 merge 接收不到数据；merge 配置内存块的文

25、件是 front-config.xml Packtclector 配置内存块的文件是 Front2000IP_linux.iniReadyDataFileMaxSize=10;(MB) 设置待处理文件最大值，一旦数据缓冲区数据累计超过此门限值，立即写入数据文件,ShareMemoryBlockNum=5 ;仅在共享内存模式下使用，表示共享内存的数目，建议值 5 解码方面选择 decode-config_forPacketcollector.xml 即可 10 版本解码配置不用选择了Merge 与信令网关对接：确定 3 个方面， All Rights reserved, No Spreading

26、 abroad without Permission of ZTE 第5页 内部公开 Internal Use Only一是要接收什么数据（ip 还是 e1 的）？根据数据类型选择对应的解码方式 decode-config_forSignalgateway.xml二是接收的那种格式的数据（0816 还是 1124）具体在 static-config 文件中的 dp10.ini 中（10 版本在merge/ini/merge.ini 中）mergememory_pool_size=6G machine_id=220 observer_mode=packetcollector observer_n

27、ame=Front2K observer_port=28000 observer_swap=500 observer_sort=1 observer_options_version=0x10000 observer_usr=zxt2000 observer_pwd=zxt2000 observer_proto_ver=199 是 0816 之前的旧版; 进程占用最大内存; 协议处理机 ID; 数据接收模式 packetcollector/ztp/sdtp; 数据接收模式辅助名称Front2K/ztp/sdtp; SDTP、ZTP 协议端口; SDTP 交换区包的个数; 是否进行排序; SDTP

28、 协议版本; SDTP 协议鉴权用户; SDTP 协议鉴权码; SDTP 格式版本，0 是 0816 版，1 是 1224 版，三是要对接的信令网关（汇聚网关）的账号、一致？、版本号是否与 dp10 程序中定义的Dp10 默认的账号为 zxt2000 zxt2000版本号码为0x10000与第三方对接的时候尤其要注意版本号，比如泰岳的版本号码就是0x10002还要注意账号后边可能带有空格，填写时要缩进好；7固网软交换版本问题目前电信的固网软交换数据中会带有 gsm-map，这个会导致我们电信版本的 cdma-map解析出错，目前只能屏蔽掉 cdma-map 的解码；今后可能会出一个针对固网软交

29、换的电信版本；8中间发送点问题要确定业务上要求将那个协议的那条消息作为发送点，然后根据下边的文档来操作即可配置中间发送点.docx这个只是 dp10 这边的中间发送点配置方法，在上层（cdrdispath 和 dataserver）还需要配置相应的过滤文件，这方面请 cs 郎林、张艳来补充9现场信息收集日志和配置现在只需执行下方的脚本，把生成的压缩包提供给研发即可 All Rights reserved, No Spreading abroad without Permission of ZTE 第6页 内部公开 Internal Use Only跟具体的现象（比如说数据库中某个字段异常或者会

30、话跟踪某个异常）有关的要求提供的原始信令（这能大大提高一些简单问题的处理速度），提供不了的要求提供连续30 分钟的原始数据10 前端机输出的 E1 链路信息总汇1.E1_Link_Check.txt，该文件在 static_config 目录下。E1_Link_Check.txt 由前端机自动创建，记录了本次前端机启动后学习到的所有链路，用于排查 E1 链路学习的完整性和正确性。HAVE_SNT_AND_SIGNALDATA：链路上既有 SNT 消息也有数据信令，表示正常链路。例：linkid=36701448, opc=16611328, dpc=16611330, event_group_

31、id=0, slc=2HAVE_SNT_BUT_NO_SIGNALDATA：链路上有 SNT 消息但没有数据信令，这样的链路可能是备用链路。HAVE_SIGNALDATA_BUT_NO_SNT：链路上没有 SNT 消息但有数据信令，这是需要重点注意的问题链路，可能是没有打开 SNT 消息，按照惯例 E1 链路需要 SNT 才能进行分段的合成。注：Linked 是 E1 头里的链路 id，09P4 以前的版本 linkid 为网络字节序。2.e1_link.ini，该文件在 merge/ini 目录下。分为两部分，一部分是配置，LINKNUM标签之前的为配置部分，另一部分是学习到的链路信息，从L

32、INKNUM标签开始后边的是第二部分，用于前端机重启过后不用重新学习以前已经学习到的链路。这里只说第二部分。例：Link1 LinkID=134217728 GlobalID=134217728 ExtID= 0SPCCodeType=24 OPC=16611328 DPC=16612605InterLinkID=0 Direction=2 LinkType=1 DataSource=1 Completed=1 HaveSignal=2CardIP=2LinkID 为 E1 头的 linkid、GlobalID 为逻辑通道号，是网络字节序；spc 较小的为 OPC，另一个为 D

33、PC； All Rights reserved, No Spreading abroad without Permission of ZTE 第7页 内部公开 Internal Use Only当信令传输方向有 OPC 到 DPC 时 Direction 为 1，否则为 2；DataSource 为信息上报者类型,1:信令采集网关，2:共享平台采集硬件，3:共享平台 SDTP 数据源；LinkType 为链路类型0:64K1:2M；3.e1_loss_stat_0.csv，该文件由程序自动生成在 merge/ini 目录下。丢包统计，以五分钟为一个周期，只显示最后一个周期的统计结果。Linke

34、d 是 E1 头里的链路 id，09P4 以前的版本 linkid 为网络字节序；当采集方式为 NCC8板时可由 linkid 解出“机架,插箱,槽位,E1 号,时隙”；主要程序模块的常见错误日志1packetcollector 常见错误日志如下：20120706 15:54:24.295 ERRORBufferManager-Ln616 BufferManager()s writeBlockMode Is UnBlock, Lost Data 1000 times. BufferMangerNo = 020120706 15:54:24.342 ERRORBufferManager-Ln61

35、6 BufferManager()s writeBlockMode Is UnBlock, Lost Data 1000 times. BufferMangerNo = 020120706 15:54:24.377 ERRORBufferManager-Ln616 BufferManager()s writeBlockMode Is UnBlock, Lost Data 1000 times. BufferMangerNo = 020120706 15:54:24.422 ERRORBufferManager-Ln616 BufferManager()s writeBlockMode Is U

36、nBlock, Lost Data 1000 times. BufferMangerNo = 02012070615:54:24.469ERRORBufferManager-Ln616BufferManager()s writeBlockMode Is UnBlock, Lost Data 1000 times. BufferMangerNo = 0产生该错误日志的可能原因：（1）确认采集上来的数据流量，数据流量太大协议处理机会处理不过来，从而导致丢包，09 版本 ieselect 两个分流的情况下可以处理 50-60M 的 MC 口数据（这个也要看机器的性能）。确认 merge 或 info

37、transform（实时和非实时）是否有堵数据的情况：（ i） infotransform 比较占用 CPU 资源，如果 CPU 占用过高，infotransform 就不再处理数据，这样就会导致 merge 和 packetcollector 丢包，这个可以通过看 CPU 和内存的使用率，正常 120M 流量 infotransform 占用 CPU 在 120%左右。（ii）如果 infotransform 之后的数据入库不畅通，同样也会导致前面模块丢包，这个可以看 infotransform 的日志是否发送正常。（iii）看 merge 是否处理不过来，merge 是比较占用内存的，通过

38、 telnet 0 8100 查看节点使用情况，看 merge 内存使用情况。（iiii）看 merge 和 infotransform 是否大量打印日志，大量、频繁打印日志会影响机器性能，导致协议处理机没有资源处理数据而丢包。（2）20120618 10:21:19.847 ERRORSharedBufferManager-Ln105 sharemem(SharedMemory_Front2K) attached too much(attach process num: 3)!, check config20120618 10:21:19.847 ERRORAssuringBufferMan

39、ager-Ln65 AssuringBufferManager(0): The aim buffer pointer is null!产生该错误日志的原因： All Rights reserved, No Spreading abroad without Permission of ZTE 第8页 内部公开 Internal Use Only可能是启动了多个 packetcollector 或者 merge 造成的。2merge 常见错误日志如下：merge 包含解码，合成，抽取和会话跟踪模块，可能会出现各种各样的日志，一般需要关注是否大量、频繁打印日志情况。（i）解码模块一般会打印一些解码错

40、误的日志，如果解码错误，有可能是数据本身错误或者程序的错误，信令可能被丢弃，会影响后面模块数据的准确性。如果是 E1 处理机，需要配置组，否则可能打印很多找不到组 ID 的错误日志。（ii）合成模块通常会打印一些找不到某某消息的日志，这个很有可能是解码或采集上来数据丢失的原因，值得注意的是，在 09P5 版本之前，E1 协议处理件decode-config_forPacketcollector.xml机使用解码配置文或decode-config_forSignalgateway.xml 时需要把 IPDatagramDuplicateRemoval 注释掉，否则可能在解码的时候有些包被过滤掉，

41、影响准确性。（iii）ie 抽取一般比较少报错误日志， 如果是节点不够用或者是信令乱序，会打印挤出失败的错误日志或者是找不到节点的错误。20120328 16:27:18.343 ERRORTLVDecodeHandler-Ln1654 ie(choi_bssap) len check, OffsetLen != CheckLen, CheckLen - OffsetLen = 12920120328 16:27:18.343 ERRORTLVDecodeHandler-Ln1654 ie(choi_bssap) len check, OffsetLen != CheckLen, CheckL

42、en - OffsetLen = 12920120328 16:27:18.343 ERRORTLVDecodeHandler-Ln1654 ie(choi_bssap) len check, OffsetLen != CheckLen, CheckLen - OffsetLen = 2720120328 16:27:18.343 ERRORTLVDecodeHandler-Ln1654 ie(choi_bssap) len check, OffsetLen != CheckLen, CheckLen - OffsetLen = 12920120328 16:27:18.343 ERRORTL

43、VDecodeHandler-Ln1654 ie(choi_bssap) len check, OffsetLen != CheckLen, CheckLen - OffsetLen = 129产生该错误日志一般是因为数据本身错误所致，是扩展的数据，我们解不了，不是CC 或者 CR 消息就不管了。20120614 09:25:30.322 ERRORERRORERRORcant find CRSCCP_COMPOSE-Ln160 CCSCCP_COMPOSE-Ln160 CCSCCP_COMPOSE-Ln160 CC20120614 09:25:31.376 ERROR tdr BSSAP_C

44、OMPOSE-Ln921 SCCP CC msg fount error event node, which DLR != 0.20120614 09:25:31.376 ERROR tdr BSSAP_COMPOSE-Ln921 SCCP CC msg fount error event node, which DLR != 0.20120614 09:25:31.376 ERROR tdr BSSAP_COMPOSE-Ln921 SCCP CC msg fount error event node, which DLR != 0.20120614 09:25:31.376 ERROR td

45、r BSSAP_COMPOSE-Ln921 SCCP CC msg fount error event node, which DLR != 0.产生该错误日志是因为 CR 消息丢失所致。 All Rights reserved, No Spreading abroad without Permission of ZTE 第9页 内部公开 Internal Use Only2012060514:57:44.372ERRORGSM_TCAP_DECODE-Ln1566 DissectParameter fail!2012060514:57:44.621ERRORGSM_TCAP_DECODE-L

46、n472 AppendMessgeVituaIE fail!2012060514:57:44.621ERRORGSM_TCAP_DECODE-Ln389 Dissect_TC_Invoke fail2012060514:57:44.621ERRORGSM_TCAP_DECODE-Ln140 Decode TCAP Message failed!2012060514:57:44.622ERRORGSM_MAP-Ln970Check_Parameter fail!, the operationCode is (201)产生该错误日志可能是因为主设备实现扩展，厂商在主设备添加了自己的操作码。2012

47、0711 19:37:58.842 ERRORERRORERRORERRORERRORto clone send itemSendWorkshop-Ln79 FailedSendWorkshop-Ln79 FailedSendWorkshop-Ln79 FailedSendWorkshop-Ln79 FailedSendWorkshop-Ln79 Failed产生该错误日志可能是因为没有足够内存来克隆结果集，需要排查哪里占用了大量内存。3xdr_datasend_cs10 常见错误日志如下：如果是 infotransform 处理不过来或者 infotransform 之后的入库堵塞，xdr_

48、datasend_cs10也会报丢包日志。如果是连接断开4infotransform（实时和非实时）常见错误日志如下：如果与 cdrdispatch 没有连接上或者断连，会打送数据失败错误日志，同时有错误返回码。（ii）多业务识别会报一些找不到的错误日志，一般是因为数据丢失导致。（iii）XDR 构建报的错误日志如果不是信令丢失导致的就是程序问题。20120528 16:59:26.936 ERRORERRORERRORERRORERRORSocketClient-Ln387 Failed toSocketClient-Ln387 Failed toSocketClient-Ln387 Fai

49、led toSocketClient-Ln387 Failed toSocketClient-Ln387 Failed to All Rights reserved, No Spreading abroad without Permission of ZTE 第10页 内部公开 Internal Use OnlySocketClient(Ret code: 2), Times: 1000020120528 16:59:28.089 ERRORBaseXDRConvertHandler-Ln170 SendXdr fail.产生该错误日志是因为没连接上或者与 cdrdispatch 断连。Merge 分流如果处理的流量变大，导