专利名称：一种基于bs告警监控方法
技术领域：
本发明涉及一种计算机通信应用技术领域，具体地说是一种基于BS告警监控方法。
背景技术：
对于传统的告警监控系统，都是采用C/S结构模式，需要在每台监控机器上安装一套监控客户端软件，而这种方式既不利于用户的使用，也不利于对客户端软件的管理和升级。随着移动办公和分布式办公越来越盛行，采用WEB模式进行告警监控更能让用户容易接受和使用。
发明内容
本发明的目的是提供一种基于BS告警监控方法。本发明的目的是按以下方式实现的，告警需要通过告警采集一> 告警处理一>告警展现流程，才能将设备上的告警在前台进行展示，因此，采用Blazeds+flex的消息推送技术，前台告警展现使用flex技术，使用flex的consumer组件订阅告警，后台通过Adobe公司的开源组件blazeds来连接jms,并且从jms接收告警,经过一系列封装处理后分发给前台，具体步骤如下:
O告警订阅、分发
前台使用flex技术展示实时告警，采用自带的组件Consumer订阅目标以接收消息，Consumer发送生成的MessageAckEvent或MessageFaultEvent消息来订阅和取消订阅，订阅后，Consumer便会为它接收到的每条消息分派MessageEvent事件，当用户登录系统后，系统会自动调用consumer的subscrib e O来和服务器建立长连接，当服务器有告警时，会回调前台的方法来进行告警处理；
2)告警展现
通过Blazeds的告警分发机制，将告警发送给每个客户端，用户登录告警系统的监控窗口即可监控告警；
每天大概几十万甚至上百万的告警，不可能将这么多的告警都展现在监控窗口中，大量的数据占用了太多的内存，从而导致浏览器崩溃，所以，系统需要设置告警监控窗口的最大容量，如果超出最大容量，按照先来后到的原则，将旧的告警从窗口中“挤出去”；
3)告警过滤
由于电信网络设备较多，告警量较大，不可能由一个人完成对全网设备的监控，要通过多个人分工合作，在东、南、西、北四个区域，设置4个监控人员，每个监控人员负责一个区域的告警监控，此时北区的监控人员不希望收到南区的告警，东区监控人员不希望看到西区的告警，此时借助JMS的Selector功能，对收到告警进行过滤筛选，不满足Selector条件的告警不会发给用户，不同角色的用户拥有不同的Selector，表示如下:
VENDOR=’huawei’ AND NETWORK=' BSS' AND REGION = ‘North’此时用户只能收到厂商是“huawei”，网络类型是“BSS”，区域是“北区”上报的告警，其他的告警不会发给此用户，从而降低客户端的压力；
4)告警缓存
针对大量的告警，用户在前台要做大量的筛选过滤操作，如果每次过滤筛选操作都查询数据库，这样在相应速度上会跟不上，而且对数据库的压力也会特别大，所以系统在前台客户端设置了一个缓存机制，将发给客户端的告警存放在缓存中，当用户在筛选过滤时直接从缓存获取告警，从而提高速度，降低对数据库的压力；
客户端根据用户所订阅的告警内容，将告警缓存到客户端，当缓存满的时候，按照先进先出的原则，将旧的告警“挤”出缓存区域，通过缓存机制保证用户的操作比较顺畅；
5)资源释放
1)关于消息的内存占用
当客户端订阅服务器成功之后，服务器会为该客户端生成客户端对象，当告警消息发往前台时，该消息就会存于客户端对象里，由于前台告警接收到消息后，服务端的消息就没有用了，为了节约内存占用，就得将消息从客户端对象删除；
2)客户端取消订阅，断开和JMS的连接
由于客户端每订阅一次，就会和JMS建立一个连接，当客户端退出时，必须将JMS的连接断开，避免不必要的连接影响性能。、
本发明的优异效果是:由于电信网络规模较大，设备较多，告警量非常大，再加上告警在不停的实时上报，最大的难题就是如何在前台展现这个告警，而且不会，采用传统的在前台使用“拉”数据的方式肯定行不通，只能采用后台“推送”的这种方式将告警推向前台。告警需要通过告警采集一> 告警处理一> 告警展现流程，才能将设备上的告警在前台进行展示，因此，采用Blazeds+flex的消息推送技术,前台告警展现使用flex技术,使用flex的consumer组件订阅告警,后台通过Adobe公司的开源组件blazeds来连接jms,并且从jms接收告警，经过一系列封装处理后分发给前台，随着移动办公和分布式办公越来越盛行，采用WEB模式进行告警监控更能让用户容易接受和使用。
图1是FM数据流 图2是消息分发示意 图3是告警订阅、分发流程图。
具体实施例方式参照说明书附图对本发明的方法作以下详细地说明。告警需要通过“告警采集”一> “告警处理”一> “告警展现”流程，才能将设备上的告警在前台进行展示。整个系统的框架如下:
由于电信网络 规模较大，设备较多，告警量非常大，再加上告警在不停的实时上报，最大的难题就是如何在前台展现这个告警，而且不会，采用传统的在前台使用“拉”数据的方式肯定行不通，只能采用后台“推送”的这种方式将告警推向前台。采用Blazeds+flex的消息推送技术,前台告警展现使用flex技术,使用flex的consumer组件订阅告警,后台通过Adobe公司的开源组件blazeds来连接jms,并且从jms接收告警，经过一系列封装处理分发给前台。告警订阅、分发
前台主要使用了 flex技术展示实时告警,采用自带的组件Consumer订阅目标以接收消息，Consumer发送生成的MessageAckEvent或MessageFaultEvent消息来订阅和取消订阅。订阅后,Consumer便会为它接收到的每条消息分派MessageEvent事件。当用户登录系统后，系统会自动调用consumer的subscribe O来和服务器建立长连接，当服务器有告警时，会回调前台的方法来进行告警处理。告警展现
通过Blazeds的告警分发机制，将告警发送给每个客户端(flex端)，用户登录告警系统的监控窗口即可监控告警。每天大概几十万甚至上百万的告警，不可能将这么多的告警都展现在监控窗口中，大量的数据占用了太多的内存，从而导致浏览器崩溃，所以系统需要设置告警监控窗口的最大容量，如果超出最大容量，按照先来后到的原则，将旧的告警从窗口中“挤出去”。告警过滤
由于电信网络设备较多，告警量较大，不可能由一个人完成对全网设备的监控，一般都是多个人分工合作。例如:有四个区域(东、南、西、北)，有4个监控人员，每个监控人员负责一个区域的告警监控，此时北区的监控人员不希望收到南区的告警，东区监控人员不希望看到西区的告警。此时可以借助JMS的Selector功能，可以对收到告警进行过滤筛选，不满足Selector条件的告警不会发给用户。
不用角色的用户拥有不同的Selector,如:
VENDOR=’huawei’ AND NETWORK=' BSS' AND REGION = ‘North’
此时用户只能收到厂商是“huawei”，网络类型是“BSS”，区域是“北区”上报的告警，其他的告警不会发给此用户，从而降低客户端的压力。告警缓存
针对大量的告警，用户在前台要做大量的筛选过滤操作，如果每次过滤筛选操作都查询数据库，这样在相应速度上会跟不上，而且对数据库的压力也会特别大。所以系统在前台(客户端)设置了一个缓存机制，将发给客户端的告警存放在缓存中，当用户在筛选过滤时可以直接从缓存获取告警，从而提高速度，降低对数据库的压力。客户端根据用户所订阅的告警内容，将告警缓存到客户端，当缓存满的时候，按照先进先出的原则，将旧的告警“挤”出缓存区域。通过缓存机制保证用户的操作比较顺畅。资源释放
1)关于消息的内存占用
当客户端订阅服务器成功之后，服务器会为该客户端生成客户端对象，当告警消息发往前台时，该消息就会存于客户端对象里，由于我们前台告警接收到消息后，服务端的消息就没有用了，为了节约内存占用，就得将消息从客户端对象删除；
2)客户端取消订阅，断开和JMS的连接
由于客户端每订阅一次，就会和JMS建立一个连接，当客户端退出时，我们必须将JMS的连接断开，避免不必要的连接影响性能。
除说 明书所述的技术特征外，均为本专业技术人员的已知技术。
权利要求
1.一种基于BS告警监控方法，其特征在于，告警需要通过告警采集---> 告警处理一> 告警展现流程，才能将设备上的告警在前台进行展示，因此，采用Blazeds+flex的消息推送技术，前台告警展现使用flex技术,使用flex的consumer组件订阅告警,后台通过Adobe公司的开源组件blazeds来连接jms,并且从jms接收告警,经过一系列封装处理后分发给前台，具体步骤如下: O告警订阅、分发 前台使用flex技术展示实时告警，采用自带的组件Consumer订阅目标以接收消息，Consumer发送生成的MessageAckEvent或MessageFaultEvent消息来订阅和取消订阅，订阅后，Consumer便会为它接收到的每条消息分派MessageEvent事件，当用户登录系统后，系统会自动调用consumer的subscribe O来和服务器建立长连接，当服务器有告警时，会回调前台的方法来进行告警处理； 2)告警展现 通过Blazeds的告警分发机制，将告警发送给每个客户端，用户登录告警系统的监控窗口即可监控告警； 每天大概几十万甚至上百万的告警，不可能将这么多的告警都展现在监控窗口中，大量的数据占用了太多的内存，从而导致浏览器崩溃，所以，系统需要设置告警监控窗口的最大容量，如果超出最大容量，按照先来后到的原则，将旧的告警从窗口中“挤出去”；` 3)告警过滤 由于电信网络设备较多，告警量较大，不可能由一个人完成对全网设备的监控，要通过多个人分工合作，在东、南、西、北四个区域，设置4个监控人员，每个监控人员负责一个区域的告警监控，此时北区的监控人员不希望收到南区的告警，东区监控人员不希望看到西区的告警，此时借助JMS的Selector功能，对收到告警进行过滤筛选，不满足Selector条件的告警不会发给用户，不同角色的用户拥有不同的Selector，表示如下:VENDOR=’huawei’ AND NETWORK=' BSS' AND REGION = ‘North’ 此时用户只能收到厂商是“huawei”，网络类型是“BSS”，区域是“北区”上报的告警，其他的告警不会发给此用户，从而降低客户端的压力； 4)告警缓存 针对大量的告警，用户在前台要做大量的筛选过滤操作，如果每次过滤筛选操作都查询数据库，这样在相应速度上会跟不上，而且对数据库的压力也会特别大，所以系统在前台客户端设置了一个缓存机制，将发给客户端的告警存放在缓存中，当用户在筛选过滤时直接从缓存获取告警，从而提高速度，降低对数据库的压力； 客户端根据用户所订阅的告警内容，将告警缓存到客户端，当缓存满的时候，按照先进先出的原则，将旧的告警“挤”出缓存区域，通过缓存机制保证用户的操作比较顺畅； 5)资源释放 1)关于消息的内存占用 当客户端订阅服务器成功之后，服务器会为该客户端生成客户端对象，当告警消息发往前台时，该消息就会存于客户端对象里，由于前台告警接收到消息后，服务端的消息就没有用了，为了节约内存占用，就得将消息从客户端对象删除； 2)客户端取消订阅，断开和JMS的连接由于客户端每订阅一次，就会和JMS建立一个连接，当客户端退出时，必须将JMS的连接断开，避免不必要的 连接影响性能。
全文摘要
本发明提供一种基于BS告警监控方法，由于电信网络规模较大，设备较多，告警量非常大，再加上告警在不停的实时上报，最大的难题就是如何在前台展现这个告警，而且不会，采用传统的在前台使用“拉”数据的方式肯定行不通，只能采用后台“推送”的这种方式将告警推向前台。告警需要通过告警采集--->告警处理--->告警展现流程，才能将设备上的告警在前台进行展示，因此，采用Blazeds+flex的消息推送技术，前台告警展现使用flex技术，使用flex的consumer组件订阅告警，后台通过Adobe公司的开源组件blazeds来连接jms，并且从jms接收告警，经过一系列封装处理后分发给前台，随着移动办公和分布式办公越来越盛行，采用WEB模式进行告警监控更能让用户容易接受和使用。
文档编号H04L12/24GK103236952SQ201310181440
公开日2013年8月7日 申请日期2013年5月16日 优先权日2013年5月16日
发明者赵宏 申请人:浪潮通信信息系统有限公司