基于日志的增值业务平台告警的设计与实现

，王红熳1，刘玉璋21.北京邮电大学交换与网络国家重点实验室交换与智能控制研究中心，北京（100876）2.得实信息科技（北京）有限公司，北京（100085）E-mail：[e-mail]摘要：本文首先总结了合作运营模式下增值业务平台的特点和平台对告警管理系统的新要求。在分析了基于SNMPTRAP协议告警管理实现方法在平台中不适用的原因后，设计和实现了一种基于应用日志实现告警管理的方法。文章最后，对该方法的优点和缺点进行了分析。关键词：电信管理网，合作运营，告警为了保障电信网络中平台不间断持续运作能力，需要在平台出现异常情况时实现迅速高效的告警管理。告警管理，在电信管理网中，属于故障管理的范畴，是电信管理网中不可或缺的一部分。目前，在电信管理网中，比较常用的告警管理是基于SNMP协议的TRAP机制来实现的。采用合作运营模式，建设电信增值业务平台，为用户提供丰富多彩的业务，是电信运营商和业务提供商合作的新形式。通过合作运营的模式，在建设和维护增值业务平台时，电信运营商可以减少初始成本投入，降低运营维护成本，将主要精力集中到业务发展上来。为保证增值业务平台的稳定运行，实现高效的平台告警管理，是建设和维护平台的重中之重。和运营商核心网络平台相比较，合作运营模式下的增值业务平台有着一些不同的特性和特点：平台规模小，数量多，在网络中比较分散，而且平台大多数位于无人值守的ICG机房，故障告警难以通过传统的声光电方式传递给维护人员；不同增值业务平台，由不同业务提供商建设，平台规发和建设风格不统一；平台建设周期短；业务在线升级和改造频繁；平台多由业务提供商自己维护，没有被纳入运营商的网管系统。虽然基于SNMPTRAP协议的告警实现方法具有良好的开放性和兼容性，能够方便地开发出针对不同的网络设备、服务器和个性应用的告警管理系统但是上述新特性，限制了其在增值业务平台中的有效应用。为了更好地实现增值业务平台的告警管理，需要寻找一种更加适合的告警管理实现方式。本文首先对合作运营模式下增值业务平台的特点和对告警管理系统的新要求，并分析了基于SNMPTRAP的告警实现方式应用在增值业务平台中的限制。在此基础上，针对合作运营模式下增值业务平台对告警管理的新要求，本文提出了一种基于应用程序日志的告警管理实现方式。该告警管理的实现方法，在和运营商合作建设的多个增值业务平台中，得到了实现和应用。1合作运营模式下增值业务平台告警管理的分析在电信管理网中，基于SNMPTRAP协议实现的告警管理系统应用广泛。它具有承载协议成熟、开发模式成熟灵活、告警时延小和能够有效减少网络带宽占用的优点[1]。但是由于合作运营模式下增值业务平台的特点和对告警管理的新要求，在增值业务平台中应用基于SNMPTRAP协议实现的告警管理受到了一些限制。1.1合作运营模式下增值业务平台的特点和对告警管理的新要求和运营商核心网络平台相比较，合作运营模式下的增值业务平台有着不同的特性和特点：1.平台规模小，数量多，在网络中比较分散。合作运营模式下的单个增值业务平台，一般只提供少数几个增值业务，所以平台规模都不大。随着业务种类的增加，平台的数量也就越来越多，部署也比较分散，而且平台大多数位于无人值守的ICG机房，故障告警难以通过传统的声光电方式传递给维护人员。2.不同增值业务平台，由不同业务提供商建设，平台规划和建设风格不统一。3.平台建设周期短。增值业务具有很高的实效性，要求业务上线速度快，这样，要求平台的建设周期短、速度快，尽快提供业务。4.业务在线升级和改造频繁。业务上线试用后对功能进行的调整和改善，在节假日业务举办促销和专区活动，需要对业务进行升级改造。5.平台多由业务提供商自己维护，没有被纳入运营商的网管系统。平台的这些特性对告警管理系统提出了新的要求：1.告警管理配置过程简单，不需要运营商的参与。由于运营商的增值业务平台众多，如果需要运营商参与或配合配置，将增加平台的建设成本和建设周期。2.告警管理的开发周期短。增值业务的平台建设周期短，则告警管理的开发周期不能过长，以保证平台按时建设完成。3.告警管理升级和改造方便。业务的升级和改造，必然会影响到告警管理的升级和改造。4.平台告警通知需要确认，特别是一些重大紧急的告警。由于平台处于无人看守的状态，则告警在通知给维护人员后，需要及时得到反馈，保证维护人员已经知晓了平台告警，以便及时进行平台恢复。1.2基于SNMPTRAP协议的告警实现方式在增值业务平台中的限制通过上一章节的分析，可以看出基于SNMPTRAP协议的告警实现方式应用在增值业务平台中受到了一些限制：1)告警管理配置和维护不灵活。增加新的告警消息后，管理者侧需要添加告警消息的OID，在配置增值业务平台的告警管理时，需要运营商维护人员参与和配合，配置过程复杂。2)实现开发工作量大，开发周期长。在新建设一个增值业务平台，或者新增加一条告警消息时，需要详细定义和实现告警消息。而且需要通知管理者，在管理者侧，开发告警消息识别程序，否则告警消息将无法识别。3)告警管理升级不灵活。如果应用添加了新告警，除了需要升级应用程序外，还需要修改和升级监控应用程序的代理，增加新的告警；为了能正确解析新增加的告警，需要修改和升级管理者解析告警的程序。在增值业务平台中，代理和管理者通常不是由相同的维护人员维护和管理的，这样在升级时还需要协调两者之间的配合，这些都不利于应用升级和系统稳定运行。4)告警无确认机制[2]。告警发出后，不能保证成功送达管理者，而且送达管理者后，无法保证维护人员已经知晓该告警，无法得到维护人员接收到该告警的反馈。这样，造成维护人员接收告警延迟甚至无法接收到告警。综上所述，基于SNMPTRAP协议的告警实现方式，不能满足合作运营模式下增值业务平台对告警管理的新要求，需要寻求一种新的告警实现方式应用在增值业务平台中。合作运营模式下增值业务平台告警管理的设计和实现通过上面的描述可知，由于合作运营模式下的增值业务平台有着区别于电信核心网的一些独特特点，使得在对这种平台实现告警管理时，不能采用基于SNMPTRAP协议的告警管理实现方法。本文提出了一种新的告警管理的实现方法，它是针对合作运营模式下增值业务平台的特点和对告警管理的新要求而设计和实现的。2.1告警管理系统设计思路设计的告警管理系统应该满足配置和维护灵活的要求。如果告警系统在配置和维护的过程中不需要运营商的运维人员的参与，则可以实现灵活的要求。可以通过在告警管理系统中同时实现告警收集和发送的功能的方法来实现改要求。告警管理系统还需要简单方便得到告警原始信息，快速响应告警信息的变化。在平台中，应用程序在运行过程中出现异常情况时，一般都会在日志文件中做相应记录。告警管理系统可以从这些日志记录的信息中得到告警原始信息，而且也能从中快速响应告警信息的变化。最后，告警关系系统还需要实现告警通知和确认机制。实现告警的通知和确认机制应该充分借助增值业务平台中的已有资源，不能增加平台对特殊资源的要求。由此，本文设计和实现了一中基于平台中应用程序日志文件的告警管理实现方式。2.2基于日志的增值业务平台告警的设计告警管理系统大致需要实现三方面的功能：1)告警信息的监控或收集；2)告警信息的处理过滤和3)告警信息的发送。基于平台应用日志的告警管理系统和系统运作流程如图2-1所示。图2-1告警管理系统及流程告警管理系统中包含3个子系统：1)监控/收集子系统。它从日志文件中不断得到异常描述信息；2)处理过滤子系统。它将异常描述格式化、过滤为告警信息；3)告警通知。它将告警信息发送给运维人员，并接收反馈，以判断是否需要重发告警信息。要实现上面设计的告警管理系统，需要解决如下问题：1)如何收集平台的异常情况？2)如何实现告警的及时传递和通知？3)如何实现告警通知的确认机制？下面对这些问题进行阐述。1.如何收集平台的异常情况。网络管理系统一般采用两种机制来实现数据的收集——轮询机制和TRAP机制[3]。轮询机制是管理者主动地逐个轮流查询被监控的对象，检查并收集对象的异常情况。TRAP机制就是通过驻留在被管对象上的代理，定期检测对象的状态，一旦发现对象的异常情况后，上报给管理者。采用TRAP机制收集异常情况，可以提高及时性，异常情况发生后，代理能够立即察觉到并通知给管理者，但是该机制需要在每个应用中提供一个代理来实现TRAP触发的功能，在增加或者删除需要监控的异常情况时，还需要修改TRAP的触发功能，这样实现的工作量比较大，而且实现的灵活度也不够。而采用轮询的机制收集异常情况，只需要实现一个完成轮询功能的管理者，不需要对平台中的应用程序做任何修改，这样实现的工作量相对较小，而且在需要监控的异常情况发生变动时，不需要对应用程序进行修改。所以，告警管理系统采用轮询的机制来收集平台的异常情况。告警管理系统周期性扫描平台中应用程序产生的日志文件，检查是否由异常情况发生。2.如何实现告警的及时传递和通知。告警一旦产生，应该尽快通知维护人员。所以，告警信息的及时传递和通知，是告警管理中关键的一环。告警信息的通知可采用多种方式：1)邮件。增值业务平台一般和互联网之间都存在接口，可以利用互联网的资源，采用邮件的形式来实现告警通知。告警信息产生后，生成一个告警邮件发送给维护人员。2)短信。如果平台和短信网关有通道，则在告警信息产生后，可以生成告警短信通知维护人员。3)语音呼叫。告警信息产生后，平台发起一个呼叫，通知维护人员。这几种方式各有优缺点。1)对平台特殊资源的要求。邮件通知的方式利用了增值业务平台中普遍存在的互联网接口资源，对其他的特殊资源没有要求；短信通知的方式要求平台和短信网关之间有连接，平台有发送短信的功能；语音呼叫通知方式要求平台中和交换机有连接，平台具有语音外呼的功能。2)告警描述的详细程度。邮件通知的方式可以在邮件中详细描述异常情况、问题原因、恢复办法等告警相关信息，而后两种通知方式由于内容篇幅的限制，只能对告警进行大概的描述，还需要运维人员进一步定位和跟踪。3)通知的及时性。大家在接收邮件时，一般是设置一定的接收间隔。这个接收间隔，影响了邮件通知告警的及时性。而短信和语音呼叫的通知方式则比较及时。因此，可以采用以语音呼叫和短信通知的方式为主、以邮件通知方式为辅的混合告警通知方式来实现告警的及时通知和告警的详尽描述。3.如何实现告警通知的确认机制。存在两种可行的告警确认机制。1)回复短信确认。运维人员在接收到告警后，可以回复一个短信给告警系统，表示已经接收到了该告警。2)接听通知电话确认。可以巧用运维人员是否接听了告警通知电话，来确认告警是否已经成功通知给了运维人员。如果运维人员接听了呼叫，则告警成功被通知，反之，告警没有被通知。采用回复短信确认的方式不能做到自动确认，需要运维人员手动回复一个短信给告警系统，告警系统还需要对短信进行分析和验证，该方式流程复杂而且不及时不可靠，可能存在运维人员接收到了告警而没有回复确认短信造成告警重复发送的风险。通过告警通知呼叫是否被接听可以自动完成确认机制，而且及时可靠。由上可知，采用第二种确认机制更加简单方便。告警管理系统在监测到新的平台告警后，主动向维护人员发起一个语音呼叫。告警系统可以从维护人员是否接听该呼叫得到反馈，从而实现了告警通知的确认机制。如果维护人员没有接听呼叫，告警管理程序间隔一段时间再次发起一个呼叫，知道维护人员成功接听、知晓告警内容为止。采用这种方式，还能避免告警被遗漏而没有通知给维护人员，也可以避免告警被重复通知。2.3基于日志的增值业务平台告警的实现上一节描述了基于平台应用程序的日志实现告警管理系统的设计和思路。基于上一节的描述，下面分别讨论各子系统的实现。告警