4G实时计费运维及优化经验.doc

中国移动通信集团河北有限公司 河北公司4G实时计费运维及优化经验一、 背景随着4G网络的发展，移动网速不断提升，极大丰富网络内容,从普通网页发展出视频、游戏、APP、电商等海量新型应用，不断促进流量业务的快速发展，同时也对系统处理能力和流量服务质量提出了更高的要求。首先，从报表数据来看，随着流量业务的不断发展，河北公司每月流量增长率约为6%10%，其中4G流量以60%的速度增长，系统压力越来越大，性能越来越紧张。一方面流量话单条数增加显着，系统性能消耗激增；另一方面建设成本高，扩容速度慢。其次，随着数据流量的激增，关于流量服务质量的投诉也逐渐增加，客户对流量计费和提醒越来越敏感，亟需从计费准确性、提醒及时性、服务有效性等方面加强业务运营监控，采取主动措施发现系统潜在的问题。从而提升流量服务水平，提高客户满意度，帮助客户及时了解数据流量使用情况，尽享上网乐趣，保证客户利益，此服务直接关系到客户体验的提升和公司社会声誉。再次，随着业务量与业务复杂度日益增加，对计费帐务系统实时性和处理能力可扩展性提出了更高的要求；全量用户数据业务实时提醒的业务，对在线计费系统的处理能力提出了更高的要求，迫切需要在线计费与离线计费、综合账务能够分离部署，避免其他业务处理对在线计费的影响；X86架构化的建设诉求，要求应用与数据解耦，应用节点支持X86刀片集群部署，BOSS系统架构发展需考虑如何实现数据与应用的解耦。基于如上背景，河北移动于2014年上线数据与应用分离的全新BDS(Billing Data Service)架构的计费账务系统以匹配如上要求。二、 当前运营过程中的风险和问题面对如上所述的背景情况，河北公司着重从建设成本和流量服务质量两方面梳理4G业务实时计费业务支撑问题和优化提升点：1、 4G业务迅速发展，BOSS系统处理的流量话单量明显增加，系统性能消耗越来越大，如何降低入口流量话单条数，降低系统性能和存储消耗是一个值得分析和研究的问题。2、 具备对所有流量客户的实时计费和实时提醒能力后，为保障实时计费的可靠性，提高客户服务满意度，需进一步监控实时计费系统运行情况，亟需一种能够识别错、漏计费的记录有效的核查方法或工具，以便验证和在线计费话单的准确性。3、 实时计费异常转离线之前，存在计费消息丢失或处理失败，消息中携带的使用量信息将无法计费，需进行计费补单，而现网“模糊补单”的机制使计费不够准确，存在“重复”或“遗漏”处理的问题，损失客户利益或减少企业收入，如何使流量计费更精准。4、 河北公司新型计费账务系统BDS上线后在应用进程管理监控、TT内存库监控告警、刀片操作系统/刀箱监控等方面提出了挑战，具体如下所列： Ø 应用进程管理监控：X86化后计费进程部署数量由3400个暴增到15000多个，新增28台刀片,已有的部署工具和操作系统自带部署工具无法满足工作需要,给运维工作带来了很大不便。Ø TT（TimesTen）内存数据库监控告警： 为了保障内存数据库的高可靠性、高性能、标准化、高可用性，引入了TT内存数据库，同时对数据库的相关指标监控也带来了挑战。Ø 刀片操作系统/刀箱监控：BDS上线后，新增28台刀片部署，针对这28台刀片急需支持监控，保障系统平稳运行。三、 解决措施及经验为解决上述4G业务发展面临的各种问题，河北公司不断研究创新，基于统计分析提出优化措施，并采取若干技术手段进行计费系统优化，降低建设成本，快速提高4G流量服务水平，助力TD-LTE业务健康发展, 在全国具有一定的参考和借鉴意义。3.1 减少BOSS系统流量话单条数, 降低系统处理和存储消耗一方面，从网元采集的话单中存在较多的无效和无意义的话单，为避免虚耗BOSS系统处理能力，为实时计费和提醒提供更多的硬件资源，需找出此部分话单并进行拦截处理。另一方面，运营商根据管理需要设置话单关闭触发条件（如：数据流量限制、时间（时长）限制、 计费条件改变等），但随着移动网速不断提升, 促使客户流量使用量激增，当前话单关闭条件引起计费话单拆单频繁，对BOSS系统处理性能造成巨大压力，影响客户流量服务质量，因此需要优化话单关闭触发条件。3.1.1 拦截异常流量话单根据业务支撑交流网站内容计费局数据-GPRS业务代码局数据，业务代码ID:2000000009（异常流量及异常信令流量），BOSS计费应对此类话单需做免费处理，且客户详单查询时此部分话单无需给客户展现。经统计某日话单情况，此类话单约占单日流量话单的25%，占比较大，虚耗BOSS系统处理能力，建议网元侧拦截或屏蔽此类话单，目前河北公司在计费做侧拦截处理，减少部分计费处理环节的消耗。3.1.2 拦截流量=0、时长=0的话单将某日客户话单按照TELNUM（客户手机号）、CHARGING_ID (计费标识：客户每次激活网络到正常下线期间的CHARGING_ID是唯一的)和service_code(服务代码：代表不同的业务种类，用于内容计费)进行合并后统计，激活网络到正常下线期间单次上网使用流量总值为0K的次数占总上网次数的比率高达30.7%。可见：即便网络侧只存在“正常下线”这一种拆单条件，当客户激活网络到正常下线期间的使用流量为0时，也会在网络侧输出话单到BOSS侧进行计费处理。然而实际上，现网存在众多的拆单条件，即使客户激活网络到正常下线期间的使用流量不为0，由于触发拆单，也会生成流量为0的话单。表1 客户使用流量行为统计表流量次数占比0K 12,271,172,432 30.70% 0-1M 4,386,404,644 10.97% 1-2M 2,048,836,748 5.13% 2M-10M 5,616,462,758 14.05% 10-30M 4,492,303,868 11.24% 30M以上11,155,249,684 27.91% 经统计某日话单情况，0流量话单条数占单日流量话单的21%（其中流量=0、时长=0的话单占比6%；流量=0、时长0的话单占比15%）。对按流量计费来说，若话单流量为0则可不处理，详单查询时也无需给客户展现；但对按时长计费来说，流量为0的话单需按时长进行批价处理。为减少BOSS系统入口话单量，降低系统消耗，建议取消按时长计费的资费，且网元侧拦截或屏蔽流量为0的话单。目前河北公司是在计费做侧拦截流量=0、时长=0的话单，减少其部分计费处理环节的消耗。3.1.3 优化“话单关闭原因19（位置信息变更/QOS变更/费率切换点）”拆单机制4G网元入网后，经统计4G全量话单，其中“话单关闭原因19（位置信息变更、QOS变更、费率切换点 ）” 的占比高达52.2% ，且占比最高。对比统计2/3/4G 全量流量话单，此种话单的占比仅为21.16%。表2 话单占比统计表拆单类型 触发因素 2/3/4G话单占比 4G话单占比 话单关闭原因0 正常下线 17.01% 10.9% 话单关闭原因17 话单时长到达30分钟29.42% 21.7% 话单关闭原因19 位置信息变更(CGI/SAI、RAI、ULI等)、QOS变更、费率切换点 21.16% 52.2% 话单关闭原因18 SGSN变更 9.59% 3.3% 话单关闭原因22 无线接入技术变更 7.10% 1.8% 话单关闭原因16 话单使用流量到达2M 5.36% 6.5% 河北公司为降低话单量，根据计费和展示需求对“话单关闭原因19”的触发因素进行了分析、简化，明确“核心网设备原则上不能开启切换enodeB产生话单的功能“。经核实只有华为公司4G网元设备开启了此功能（中兴、爱立信均关闭状态）。目前河北公司于2015年2月4日凌晨在网络侧关闭华为公司4G网元“切换enodeB产生话单功能”，为观察关闭此功能后的效果情况：统计比对2月2日和6日的华为4G设备话单的拆单情况：“话单关闭原因19”触发的拆单话单量占比由62%降为39%。统计对比2月2日和6日的华为4G设备的话单量和流量值：流量值基本持平情况下，关闭后华为4G网元产生的话单条数下降25%左右。3.1.4 优化“话单关闭原因16（话单使用流量到达2M ）”的拆单机制将某日客户话单按照TELNUM（客户手机号）、CHARGING_ID (计费标识：客户每次激活网络到正常下线期间的CHARGING_ID是唯一的)和service_code(服务代码：代表不同的业务种类，用于内容计费)进行合并后统计,如图1所示，激活网络到正常下线期间单次上网使用流量总值>2M的次数占总上网次数的比率高达53.2%，可见“话单使用流量到达2M”切割机制不太符合客户（尤其是4G客户）的使用行为，为减少BOSS系统入口话单量，河北公司将4G离线话单按照10M拆单，理论上由流量到达触发的拆单量降低80%，但考虑到其他拆单因素的影响，保守估计流量值基本持平情况下，4G话单条数约下降10%左右。3.2 实施稽核和精确补单，加强在线计费业务监控和异常自动化处理随着实时计费能力的不断提升，进一步加强对数据业务在线话单处理异常情况下的核查跟踪和业务运营监控，河北公司在集团公司的指导下，实施在线计费一致性稽核和DCC消息稽核。为进一步加强对稽核工具输出的异常结果的处理效率，河北公司对稽核结果为 “在线和离线均有，但流量有差异”的话单实施自动化“精确补单”机制，避免实时计费异常转离线之前，因计费消息丢失或处理失败而漏计费的问题，减少企业损失。3.2.1 计费一致性稽核计费一致性稽核是通过定期对DCC消息、在线计费话单、离线过滤话单进行分析和匹配，以TELNUM，CHARGING_ID，GGSN字段作为键值对GPRS话单的数据流量进行稽核，识别错、漏计费的记录，用于验证和稽核在线计费话单的准确性。通过对稽核不一致的会话的分析，定位出现网配置问题、计费规则问题、规范符合度以及网元问题等与在线计费相关的各个方面存在的问题。整体稽核流程如图1所示：图1 稽核流程（1）源话单采集参与计费一致性稽核的三类话单的采集流程如图2所示：消息话单：通过直接采集GGSN与DCC_DISP消息分发之间的DCC原始数据包，经过解析保存为DCC消息消息话单。离线过滤话单：分拣的GGSN、P-GW话单中若PS-FCI信息为16，则代表在线计费成功，在离线计费中应过滤不处理，将此部分拦截的在线计费客户产生的离线话单做为稽核的依据之一。在线计费话单：通过融合计费和话单实例化生成的在线计费客户产生的在线话单。图2 稽核话单的采集流程（2）源话单合并对上游传来的在线计费详单、离线过滤话单、消息话单分别进行处理：首先以TELNUM，CHARGING_ID，GGSN作为关键因素，把一次上网产生的多条话单按照关键因素进行会话合并；其次判断合并话单的完整性以决定是否输出合并话单，并根据是否满足参与稽核的条件进行稽核判断；最终合并后的话单以最早一条话单的开始时间为准。由于话单处理延时、资源限制等因素，并不是所有的话单均能按照会话进行完整的合并，判断是否进行合并输出参与稽核的条件如下所述，满足其中任意一条即可：Ø 若首张话单的开始时间和末张话单的开始时间差等于同一会话的所有话单的时长之和时，认为话单全部到齐。但考虑到设备时差或切换设备耗时情况，首末话单的时间差与时长之间的误差在5秒内都认为是到齐的，合并输出让其参与稽核。Ø 若首张话单和末张话单均到达后，那么从最后到达那张话单（首单或者尾单）开始计时，等1小时后，不管会话是否完整，让所有到达话单合并输出参与稽核。Ø 若首张话单和末张话单尚未全部到达，那么从最后一张到达的话单到达后开始计时，等2小时后，若没同一会话的任何话单到来，则不管会话是否完整，让所有到达话单合并输出参与稽核。Ø 若首张话单和末张话单尚未全部到达，且每隔2小时内均有同一会话的话单到来， 那么从第一张到的话单开始计时，等24小时后，不管会话是否结束，强制让所有到达话单合并输出参与稽核。（注：当有大量超过一天不下线的4G用户时，可适当调整参数，如将“24小时”调整为“48小时”。）（3）合并话单散列合并话单散列的主要目的是按规则进行分组或队列，以便后续每个组或队列并行进行稽核处理。具体处理方式为：根据键值字段（TELNUM，CHARGING_ID，GGSN）计算出对应的散列值，将合并后的话单根据散列值按设定的散列区间取模，写入不同的文件中，具有相同取模的多个合并话单能够写入同一散列文件中，最后根据散列文件的数量启动若干个稽核程序进行处理。（4）稽核处理对合并且散列后的在线话单和离线过滤话单、消息话单和离线过滤话单、消息话单和在线话单分别进行稽核。首次稽核只对参与稽核的会话话单打标记，不记录和输出结果；4小时后按照键值（TELNUM，CHARGING_ID，GGSN）对新增的会话话单进行再次合并，并对打标记的会话话单再重新稽核一次；若有差异，则输出差异结果。综上，对参与稽核的会话按每4小时一次进行稽核，每次会话稽核两遍，两遍后输出稽核结果。 图3 稽核处理示意图Ø 第一次稽核时，待稽核的话单中有会话S1、S2、S3，不管这三个会话是否有差异，都不进行输出稽核结果，只对话单打戳；Ø 第二次稽核时，新增了会话S4、S5、S6、以及S1（S1会话的延迟话单），则系统首先将S1与会话S1进行合并处理，然后稽核，输出第一次稽核打戳的所有会话的稽核结果，同时对会话S4、S5、S6进行打标记；Ø 第三次稽核时，同样先检查是否有第二次稽核时会话的延迟话单，有则合并，然后对第二次稽核打标记的会话输出稽核结果，最后对本次首次稽核的会话打标记。（5）稽核结果展示计费一致性稽核工具对稽核结果进行统计后以报表的形式通过界面直接展示，显示出每一稽核周期总共参与稽核的在线会话多少次、消息会话多少次、离线会话多少次、一致会话多少次、不一致会话多少次等信息，并对统计后的稽核数据进行编码输出告警接口文件。Ø 在线话单和离线过滤话单的稽核结果分类：表3 在线/离线稽核结果分类情况分类稽核结果输出内容会话一致在线和离线均有，并且流量一致可选择是否输出会话不一致在线无，离线有输出离线话单作为差异在线和离线均有，但流量有差异输出差异分类流量在线有，离线无输出在线话单作为差异Ø 消息话单与在线、离线过滤话单的稽核结果分类：表4 消息/话单稽核结果分类情况分类稽核结果输出内容会话一致消息和在线（离线）均有，并且流量一致可选择是否输出会话不一致消息无，在线（离线）有输出在线（离线）话单作为差异消息和在线（离线）均有，但流量有差异输出差异分类流量消息有，在线（离线）无输出消息话单作为差异Ø 以在线话单和离线过滤话单的稽核为例，统计报表展示如下：图4 稽核结果展示（6）不一致的会话详单对于稽核结果为不一致的会话话单则存储在稽核系统的“异常详单表”中，其中cdr_gprs_error为在线/离线异常详单表, cdr_dccon_error为消息/在线异常详单表，cdr_dccoff_error为消息/离线异常详单表。另外，通过error_flag字段来标识稽核结果类型，通过on_total、off_total、dcc_total字段来记录同一会话各种稽核话单的流量值，便于进一步查询差异的详细信息。图5 稽核不一致会话详单表内容3.2.2 DCC消息稽核DCC消息稽核是采用hadoop技术将海量的DCC消息信息进行云存储，一方面分时段统计并展示在线计费相关信息：Session数、本地漫入漫出标识、上行流量总数、下行流量总数等。另一方面稽核消息的完整性和连续性，对异常结果设置不同级别的告警。从而通过DCC消息稽核系统实时监控网元和计费系统之间的消息交互运行情况，及时获取交互异常信息。DCC消息稽核的整体逻辑处理流程如下：图6 DCC消息稽核的处理流程Ø 生成消息话单文件：将dcc_store生成的信令文件转换成消息话单文件,用于稽核。Ø 数据保存到HBase库：解析dcc_store生成的信令数据文件，解析后保存到Hadoop的HBase中，用于进行消息统计与检查。Ø 对消息话单的统计：从hbase读取消息话单,对Session数、本地漫出标识、上行流量总数、下行流量总数进行统计汇总。l 输入：统计的开始时间、统计的结束时间l 处理过程：遍历DCC消息话单表，对Session数、本地漫出标识、上行流量总数、下行流量总数。使用MAPREDUCE对数据进行统计，按RowKey进行MAP，并将最终结果进行汇总。上行流量总数：来源CC-Input-Octets的累加。下行流量总数：来源CC-Output-Octets的累加。本地漫出标识：根据DCC消息的SessionId中的DiameterIdentity进行本地漫出类型判断。l 输出：类别（local、roamout）、Session数、上行流量总数、下行流量总数。Ø 消息完整性稽核：从hbase读取消息话单，进行消息完整性稽核，稽核规则是对于每个CCR是否都有CCA与之匹配。l 输入：日期，如：20150320l 处理过程：根据日期进行稽核，遍历保存在HBASE中DCC消息表的数据，判断每个会话内CCR与CCA都是匹配的（根据CC-RequestNumber，要求每个CCR都有对应的CCA），否则完整性稽核不通过。并考虑SESSION的时间段的与稽核日期的开始、结束的时间点重合的特殊情况(根据消息中的EventTime与统计日期判断，会话的EventTime存在不在此统计日期内的，则不进行稽核)，对于此类情况，不进行稽核。对于跨天的会话，需要参考上/下一天的数据。l 输出：记录到ORACLE数据库，稽核结果日志表与稽核结果异常数据表。Ø 消息连续性稽核：从hbase读取消息话单，进行消息连续性稽核，稽核规则是在每个Session中CC-RequestNumber是否连续。l 输入：日期l 处理过程：根据日期进行稽核，遍历保存在HBASE中DCC消息表中的数据，针对每个会话，判断CC-Request-Number是否是从1依次递增，并判断INIT类型消息的CC-Request-Number是否是1，CC-Request-Number最大一个消息是TERM类型，否则连续性稽核不通过。并考虑SESSION的时间段的与稽核日期的开始、结束的时间点重合的特殊情况，对于此类情况，不进行稽核。对于跨天的会话，需要参考上/下一天的数据。l 输出：记录到ORACLE数据库，稽核结果日志表与稽核结果异常数据表。Ø 稽核结果展示：通过界面展现稽核结果日志表与稽核结果异常数据表的数据。图7 DCC消息稽核的结果展示Ø 告警：判断稽核不通过的数量是否超过特定值，若是则可通过BOMC进行告警。3.2.3 精确补单通过计费一致性稽核会输出“在线和离线均有，但流量有差异”的不一致的会话信息。产生原因之一就是实时计费异常转离线之前，存在计费消息丢失或处理失败，消息中携带的使用量信息将无法在线计费，但此时离线话单中的PS-FCI=16，仍进行过滤处理。此种情况需匹配寻找相对应的拦截的离线话单进行补单，而现网“模糊补单”操作是将在线异常话单的开始时间粗略的往前追溯一定时间（如1分钟）找到此刻后所有的离线话单进行计费处理，且不区分2/3/4G、不区分业务都是统一追溯1分钟，势必会对使用4G网络或高清视频等业务的客户造成重复处理，对使用2G网络或QQ业务的客户造成遗漏处理的后果。给企业带来收入损失，并影响客户满意度。图8 “模糊补单”误差分析（1）“精确补单”处理方案河北公司优化补单处理流程，建立“精确补单”机制，处理方案如下图所示： 图9 精确补单处理方案图在线话单：由网元发出的消息经计费系统处理后，直接生成客户话单。离线拦截话单：有在线服务标识的客户，其离线文件和在线消息携带信息是一致的，故此部分离线文件（PS-FCI=16）经处理后将会被过滤拦截处理。异常线索话单：在线处理异常时，在线话单存在使用量信息不全的问题，需补单处理，而此时网元会立即关闭正在记录的离线文件，后续转离线处理。故选择异常时有关闭操作的离线话单（PS-FCI=16 、CAUSE-CLOSE=20）作为线索。精确补单模块：以异常线索话单、离线拦截话单、在线话单作为精确补单模块的输入，通过分业务比对分析计算出需“回捞”的信息，输出待补话。待补话单：经精确补单模块分析判断直接输出待补话单，或匹配修改相关信息后输出待补话单，最后将待补话单进行重处理操作，使得稽核结果为“在线和离线均有，但流量有差异”的部分话单得到精确的补单处理。（2）“精确补单”处理流程 精确补单模块的详细处理流程如下图所示：图10 “精确补单”处理流程图步骤1：获取异常线索话单在线处理异常时，GGSN、P-GW立即关闭正在记录的离线话单，关闭原因为management Intervention（20），PS-FCI为16，后续整个PDP所有业务均转离线处理，PS-FCI为11；而此时在线异常话单存在信息量不全的问题。故根据稽核系统不一致会话详单表中稽核结果为“在线和离线均有，但流量有差异”的键值，在采集源话单中分流出PS-FCI=16 、CAUSE-CLOSE=20的离线拦截话单作为线索进行补单处理。步骤2：离线话单排序、检查一条话单就是一组由多个不同的数据类型的变量组成的结构体CDR，同一TELNUM，CHARGING_ID，SERVICE_CODE对应的m条离线拦截话单可标记为：按拆单序列sequence进行倒排，并检查顺序是否完整，若否则输出异常信息：步骤3：计算m条离线拦截话单上下行总流量：步骤4：在线话单排序、检查目前在线的拆单频率与离线拆单机制不一致，BOSS系统时钟与GGSN时钟存也不一致，故两者话单的开始时间和话单条数也不同，同一TELNUM，CHARGING_ID，SERVICE_CODE对应的n条在线话单可标记为：按拆单序列sequence进行倒排，并检查顺序是否完整，若否则输出异常信息：步骤5：计算n条在线话单上下行总流量：步骤6：补单是补充离线拦截的话单，若离线话单采集过程中丢单或流量异常，则输出异常信息。步骤3和步骤5是判断是否丢单，本步骤是判断流量是否异常：步骤7：补单的原因是在线处理异常时无term消息实例化出来的在线话单存在信息量不全的问题，故需匹配寻找相对应的离线话单进行补充，可见应从离线拦截话单的末条话单开始逐一比对时间、流量等关键字段。为保证补充的话单与正常话单在时间上能“无缝衔接”，从末条离线话单开始，依次判断每条离线话单的开始时间与末条在线话单结束时间：（1）若前者小于后者，则直接修改本条离线话单开始时间、时长和流量作为待补话单进行重处理。判断条件：修改离线话单作为待补话单： （2）若前者大于等于后者，为保持离线话单的“原貌”，先判断离线话单的流量是否小于等于在线异常丢失话单的总流量，若是则说明该条话单不用修改，直接作为待补话单进行重处理。判断条件（3）若前者大于等于后者，且离线话单的流量大于在线异常丢失话单的总流量，则需要修改本条离线话单开始时间、时长和流量，完成修改后重处理进行补单操作。判断条件修改离线话单作为待补话单：（3）“精确补单”小结以拦截的离线话单（PS-FCI=16、CAUSE-CLOSE=20）为异常线索话单，通过比对分析异常前实时计费话单和在线拦截的离线话单，从离线拦截话单的末条话单开始逐一比对时间、流量等关键字段，精确计算异常前需补充计费的话单。使实时计费异常前补充的话单在流量和时间上都能达到精准衔接，保障客户利益，减少企业损失。实施精确补单后，实时计费与离线计费的一致率由99.96%提高到99.99%，提高实时计费的准确性。 3.3 加强基于云架构的业务应用和系统监控，提高运营可视化3.3.1 应用进程管理监控工具引入为了实现计费15000进程在28台刀片的界面化部署、监控管理，提升运维人员工作效率，河北公司引入应用进程管理监控界面化工具，实现应用进程界面化管理及告警界面化展现与配置，其功能架构如下所示：图11 应用进程管理监控功能框图主机代理其主要功能：Ø 被动接收调度进程的请求，并做相应处理，如启动某个进程、终止某个进程等Ø 监控进程状态，主动上报进程状态，当进程状态发生变化时，主动将状态上报给调度进程。同时，也提供进程状态全量上报接口。Ø 主机资源状态监控，并将及时将资源使用情况上报给调度进程。Ø 提供文件上传接口Ø 具备扩展的能力，如后续可以增加在本地执行命令的能力，以用于其他应用如中间件的发布。调度进程主要功能：Ø 调度管理进程的能力Ø “主机代理”的代理：通过调度进程可以访问主机代理的所有能力，因为主机代理同客户端在网络极可能是不通的。Ø 告警管理：收集告警、展现告警、清除告警等。系统界面如下：图12 应用进程管理监控系统界面3.3.1.1 通用的插件化体系调度程序和主机代理程序都基于相同的插件框架实现，所有功能都通过插件来实现，所谓插件就是：动态库配置文件。插件框架提供的能力：l 通用的对外服务接口，接口形式同营业SrvCall、BkUniCall，不过限定了可用于传输的CBO，只支持CTagSet系列的CBO。l 提供插件自动更新能力：框架自动搜索插件目录，自动激活没有加载的插件和发生变更（配置或执行文件）的插件，自动去激活配置为非活动的插件。l 提供通用文件上传接口：此功能和插件自动更新一起可以完成系统在线升级。3.3.1.2 避免单点u 调度进程单点解决方案图13 调度进程单点解决思路系统部署2个调度进程，在程序启动时首先到数据库申请一个锁（for update一条记录），申请到锁的进程负责调度。同时主进程还跟备用进程保持“心跳”，如果“心跳”断开了，这时候可能是对方“死”掉了，也可能是网络断了，两者都会重新去“抢”这个锁，抢到者上升为主调度进程。u 应用主机单点解决方案调度进程支持部署在多台主机上，调度进程优先选择“Master”主机，如果“Master”主机down掉，则从“备用资源池”种选择一台空闲主机。（“备用资源池”为预先定义好的一组运行环境完全相同的主机）。u 数据库单点解决方案1)主机代理不访问数据库，所有数据库操作都由调度进程完成2)主调度进程跟备用调度进程连不同的数据库实例，在主调度进程连接的实例DOWN掉时，主调度进程将交出“调度权”，备用进程开始工作。3)数据库应及时做好备份工作。如果数据库坏掉，进程运行状态仍然能够从主机代理上获得，其他配置信息从备份中恢复。3.3.1.3 过载保护过载保护指在主机CPU利用率达到设定阀值时，调度进程所做的保护措施：l 主机性能告警：生成一条告警，提示维护人员关注系统运行状况l 停止优先级最低的进程：主动停止所有优先级最低的进程。l 停止向负载过高的主机分发调度任务：需要调度的任务改为到“备用资源池”。为了安全，调度进程不会主动“迁移”正在运行的、优先级较高的后台进程。3.3.1.4 进程状态异常告警l 异常终止告警：对于关键进程，当其异常终止时系统自动产生告警，提示维护人员关注。l 心跳告警：如果进程在设定的时间内没有心跳，将产生告警，并根据设置对进程进一步处理，如强制终止该进程。l 执行时间过长告警：如果进程运行时间超出设定限制，将产生告警，并根据设置对进程座进一步处理，如强制终止该进程。这对于一些按时间段运行的后台进程非常有用。3.3.1.5 进程特性l 调度方式：分为手工调度和按时调度两类，按时间调度的规则同crontab。l 调度优先级：分为高、中、低三个档，总是优先调度高优先级的进程，低优先级的进程，在资源紧张的情况下，可能会被“迁移”，或者得不到调度。l 心跳时间间隔及处理方式：可以设置心跳时间及处理方式，处理方式分为告警和终止两种。l 进程运行最长时间及处理方式：可是设置运行时长及处理方式，处理方式分为告警和终止两种。l 进程状态：这里指进程逻辑处理的状态，如“准备就绪”、“空闲”等，这个状态为后面提到的组合任务调度提供依据。l 是否需要发送状态通知：可以在进程状态发生变化时发送告警通知，如进程异常终止、进程心跳告警、进程运行时间超长等。3.3.1.6 支持子进程监控提供子进程注册接口，仅监控成功注册到系统的子进程，不会主动搜索子进程。也就是说只监控需要监控的子进程。基于当前技术，该功能有下列局限性：l 只提供查看功能，子进程的启动、管理由父进程负责。l 父进程停止后，所有子进程信息将被删除，即父进程必须同子进程一起存在。3.3.2 TT内存数据库监控告警 TT内存数据库的监控告警采用TTSQL语句获取相关指标数据，根据指标阀值进行监控告警，告警模式有BOMC界面展示、短信通知、工单处理。 河北公司对TT内存库的关键业务点进行统计分析，形成相关监控指标如下：表5 内存数据库监控指标指标名称周期阀值PERM内存空间高水位30分钟N/APERM内存空间使用量30分钟N/APERM内存空间高水位占用率30分钟85%/90%PERM内存空间使用率30分钟85%/90%TEMP内存空间高水位30分钟N/ATEMP内存空间使用量30分钟N/ATEMP内存空间使用率30分钟85%/90%TEMP内存空间高水位占用率30分钟85%/90%监控死锁数量1小时N/A监控事务回滚数量1小时N/A内存库的状态检查（1 ACTIVE,0 STANDBY，2 IDLE）5分钟N/A内存库复制状态是否发生变化（0：nochange，1：active to standby 2:standby to active 3 standby or active to idle）5分钟N/A长事物的个数（ttLogHolds 关键字：Long-Running 长事物的个数）15分钟=8长事物数的增长量 （ttLogHolds 关键字：Long-Running）15分钟=5单个长事物持续出现的采集次数15分钟=3内存最大空闲块1天N/A内存库主备机是否都为standby或active（0：warn，1：OK）5分钟0连接数使用率5分钟80%内存库Daemon进程状态2分钟0内存库Server进程状态2分钟0内存库复制进程状态2分钟0时钟同步延迟时间10分钟0.25“长事物的个数”指标监控示例：uid=用户名;pwd=密码;dsn=accounta2 ，登陆过程如下：ttisql “uid=用户名;pwd=密码;dsn=accounta2 ”Copyright (c) 1996-2011, Oracle. All rights reserved. Type ? or "help" for help, type "exit" to quit ttIsql. connect "uid=用户名;pwd=密码;dsn=accounta2" Connection successful: DSN=accounta2;UID=用户名;DataStore=/datadsc3/accounta2/accounta2;DatabaseCharacterSet=WE8ISO8859P1;Connect ionCharacterSet=WE8ISO8859P1;LogFileSize=1024;DRIVER=/timesten/ttadmB/TimesTen/ttB/lib/libtten.a;LogDir=/logdsc3/accounta2;PermSize= 35840;TempSize=4096;LockWait=2;Connections=1024;CkptRate=50;CkptFrequency=600;RecoveryThreads=12;TypeMode=0;PLSQL=0;LogBufMB=1024;Re ceiverThreads=1; (Default setting AutoCommit=1) 执行的指令  通过“call ttLogHold”指令获取内存库长事务数，如下所示一共3条。call ttLogHolds;  < 438, 357064704, Checkpoint , accounta2.ds1 > < 438, 357478400, Checkpoint , accounta2.ds0 > < 438, 357560568, Replication , QDBDSC2:ACCOUNTA2 > 3 rows found. exit; Disconnecting.PERM内存空间高水位指标示例：uid=用户名;pwd=密码;dsn=accounta2 ，登陆过程如下：ttisql “uid=用户名;pwd=密码;dsn=accounta2 ”Copyright (c) 1996-2011, Oracle. All rights reserved. Type ? or "help" for help, type "exit" to quit ttIsql. connect "uid=用户名;pwd=密码;dsn=accounta2" Connection successful: DSN=accounta2;UID=用户名;DataStore=/datadsc3/accounta2/accounta2;DatabaseCharacterSet=WE8ISO8859P1;Connect ionCharacterSet=WE8ISO8859P1;LogFileSize=1024;DRIVER=/timesten/ttadmB/TimesTen/ttB/lib/libtten.a;LogDir=/logdsc3/accounta2;PermSize= 35840;TempSize=4096;LockWait=2;Connections=1024;CkptRate=50;CkptFrequency=600;RecoveryThreads=12;TypeMode=0;PLSQL=0;LogBufMB=1024;Re ceiverThreads=1; (Default setting AutoCommit=1) 执行的命令为"monitor;"TIME_OF_1ST_CONNECT: Sun Feb 8 11:46:12 2015 DS_CONNECTS: 138062 DS_DISCONNECTS