江苏电信iTV服务质量监测系统

目录

1.... 全省跨越组播CR监测点分布... 3

2.... 视频分析仪断流判断依据... 4

3.... 2015.2.7 《时尚女人》频道告警工单异常分析... 4

4.... 原因分析... 6

1     全省跨越组播CR监测点分布

2014年江苏电信iTV全省完成了跨越组播改造，iTV监测系统视频分析仪监测点从原区域中心节点上浮到各地市CR。如下为拓扑架构

2     视频分析仪断流判断依据

断流判断是以视频分析仪监测的某一频道无ts报文为依据 ，产生告警，达到断流告警配置的时间阈值

时间阈值指断流持续时长触发的告警配置，如配置触发5秒，即断流5秒后触发告警，以断流产生时间为告警起始时间

视频分析仪支持配置秒级监测，当前江苏13个地市视频分析仪CPU性能目前60-70%，无性能瓶颈问题

3     2015.2.7 《时尚女人》频道告警工单异常分析

根据iTV全网跨域组播组播流金字塔 结构

江苏省台 节目源（游府西街 iTV入 监测点  ) -----省中心 (平台转码，二长 iTV出  ) -------13个地市---区县---终端用户

2015.2.7 （周五）下午14:33:51，省电信平台部接到工单提醒，有《时尚女人》频道断流，地市为徐州、盐城、南京，

而且在同一时间，但省中心只有游府西街出现告警，而二长省中心没有出现告警信息

不符合告警逻辑

联合研发排查如下

1）   视频分析仪监控日志videomon.log无异常

2）   后台原始数据排查

原始告警表（13个地市视频分析仪监测告警数据入库表）：

select m.name,t.*

from channel_alarm t

join rlt_monitor_channel_addr s

on s.id = t.rlt_id

join cfg_channel_addr p

on p.id = s.channel_addr_id

join cfg_channel o

on o.id = p.cfg_channel_id

join video_monitor m on m.id=s.video_monitor_id

where o.channel_name = ‘时尚女人‘ and

t.alarmtype=1 and t.alarm_time >to_date(‘2015-02-07 13:00:00‘,‘yyyy-MM-dd HH24:mi:ss‘)

order by t.alarm_time

PS:// alamtype=1 即为断流

查询13个地市所有监测点上报的原始告警单中发现都有断流

原始表见如下附件

4     原因分析

为何原始告警数据已经入库，而GUI前台及发给iTV综合网管北向接口发只发了4条告警

1） iSA 后台逻辑：后台代码 channel_outage表会对 原始表channel_alarm进行实时判断汇总，并实时处理发给iTV综合网管

2） 经我司SE 昨晚加班排查代码，发现代码覆盖不全，在channel_alarm表进行实时处理时，那些地市没有展示的表数据被误认为异常数据进行了抛弃

导致没有入库channel_ouage表，但前台展示和实时告警数据都依赖于channel_outage表数据，所以导致展示和派单信息不全

改进建议

1） 更新代码，重新评估改部分运维逻辑

2） 计划安排优先重新审议review相关涉及到运维功能部分代码