断流告警省中心-地市不一致派单分析

江苏电信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相关涉及到运维功能部分代码

 

原文地址:https://www.cnblogs.com/iclk/p/4288731.html