气象实时数据库服务监控系统设计与实现

李德泉, 何文春, 阮宇智, 刘一鸣

(国家气象信息中心,北京100081)

0 引言

实时气象资料数据库系统(以下称“实时数据库”或“实时库”)作为“国家级气象资料存储检索系统”(MDSS)[1]的重要组成部分,是气象信息部门针对预测预报及相关业务开发的重要数据服务系统,是确保从观测到预报业务流程按时高效完成的重要基础性数据支撑环境。实时数据库系统对实时气象资料进行接收、分类、加工处理,并以地面气象资料、高空气象资料、海洋气象资料、气象辐射资料、农业气象资料、数值分析预报产品资料、气象灾害资料、气象卫星资料、气象服务产品资料和其他资料等12类资料形式存储并实现资源共享。

所谓实时(Real-Time),是指数据库应用系统一方面要维护大量共享数据和相关用户信息,另一方面其应用服务有很强的时间性,要求在一定的时刻或者一定的时间期限内从外部环境采集数据,经规范化处理后,以有效的数据组织形式存储,并及时响应随后的大量并发访问服务。因此,整个数据处理过程具备短时、高效特点,并且每种资料对数据服务时效具有明确要求,过时则无意义[2]。

气象实时数据库不仅作为关键数据源连接气象中心、公共气象服务中心等部门的实时业务系统,还为科研用户提供一定时间期限内数据查询下载服务。因其在整个业务流程中发挥关键的底层支撑作用,其服务稳定性及时效将直接影响其服务对象的实时业务效能和气象预报及时性与准确性,进而影响气象部门对内外行业用户、公众用户的气象服务质量,因此从业务运行开始就一直作为国家气象信息中心的运维重点。

为了保障实时数据库系统稳定对外服务,协助值班人员日常值班,实时动态地监测各类气象实时观测资料的到报、入库质量,以及实时库处理相关线程的运行状态,国家气象信息中心组织技术力量,开发完成实时气象资料数据库业务监控系统(RDBCat,以下简称“实时库监控系统”),并在2008年奥运会期间业务上线运行。

1 实时数据库监控系统设计思路

1.1 基于服务监控系统的通用性设计

作为针对实时气象数据库服务业务的监控系统,系统核心设计目的是针对实时库的运算环境及健康状况进行即时监控与报警,确保实时数据服务能稳定支撑业务使用。因此可归类为服务类监控系统(Service Monitoring and Control,SMC)[3]。

服务监控系统重点负责对信息服务系统运算环境及健康状况进行即时监控,动态显示服务成功或失败的可辨识特征,并对服务异常状况报警。此外,服务监控还负责收集服务故障相关上下游运行环境及流程信息,进而协助使用部门改进IT服务质量。

服务监控系统往往以分布式方式采集来自于信息服务系统各相关设备、应用程序的日志信息和告警事件信息,判断服务故障事件,快速定位故障事件的来源,分析故障发生的根本原因,集中展示信息服务系统运算环境及整体安全状况。一旦发现高风险服务故障事件还可触发相应故障事件处理流程,督促值班人员及相关责任人进行快速排查问题和解决故障。

服务监控系统从体系架构上可划分为4层:信息基础层、数据采集层、数据及规则处理层、展示层4个层面,各个层面功能各不相同。整体架构如图1所示。

信息基础层为整个系统提供基础设备及软件运行环境(网络设备、安全设备、业务系统、服务器等),其同时也是各类监控信息的数据获取来源。

数据采集层:根据系统内部指定的运维策略,借助由专用的数据采集引擎,数据采集层负责从信息基础层采集各种报警信息、日志信息、流量信息,经过数据格式标准化、数据归并、统计等处理后,形成原始数据,提交给上层的数据及规则处理层。

数据及规则处理层:将采集到的原始数据按照业务系统数据、设备数据、网络及安全数据等进行分门别类,经过基于统计、基于规则的关联分析后,科学合理地定义各类故障事件的性质和处理级别,作为展示层的数据基础。

展示层:实现整个服务监控系统的灵活展示和配置管理。通过丰富的、多元化、分层次的图形化展示方式呈现各个监控对象的运行状况,提供有效的安全预警,减免严重故障的发生,快速应对突发故障并降低所造成的损失。

总之,一个设计良好的面向服务的监控系统应该至少具备如下完整因素:明确的监控对象,涵盖所有业务需要关注的场景并提示给使用者简明清晰必要信息,监控信息明确分类并具有界面友好的处理建议,当然,其他方面诸如快速部署、扩展性、标准化等根据实际需求也必须有所侧重。同时,与之匹配的业务运维架构尤其是监控流程和运维岗位设置等管理性内容也会对监控系统设计及发挥效益起着至关重要的先决制约作用。

图1 服务监控系统体系架构

1.2 基于业务值班需要的监控功能设计

鉴于服务监控系统主要用户为一、二线值班人员,作为业务值班监控系统,其设计思路上还应充分考虑业务值班特点:支持声音报警;支持监控信息集中“一页式”定制显示,使报警信息及统计信息一目了然,不需要手工繁琐操作;简单易行的策略配置操作;监控信息按错误类别分类,用户可定制哪些类别在监控屏幕显示,屏蔽不关心的信息提示,避免值班干扰;具备故障处理向导,帮助值班人员与后台技术人员沟通。

值班运维业务架构采用一线、二线两个级别。一线值班并报告故障内容,二线值班负责排查并去除故障,之后反馈一线。

同时,业务监控系统还应作为二线进行故障追溯和关联分析的辅助工具。

1.3 基于气象实时业务数据处理通用流程的设计需求

1.3.1 典型的实时数据库业务数据流程

实时库作为系统的监视对象,其流程直接影响系统的监视内容的设计,以图2典型的实时业务流程进行简要分析说明。

流程中,报文数据首先进行入库前预处理,报文经过格式检查并解析后按照分类归并,再存放于一定目录组织形式的临时文件库中,格式检查错误信息被写入日志。入库处理进程从临时文件库中提取数据并存入关系型数据库或文件库中,期间经过质量控制算法发现的异常值写入要素异常值日志。对外服务平台从数据库中提取信息,以程序接口、文件推送、查询服务等多种形式对外提供实时数据服务。

图2 实时数据业务流程

1.3.2 监控对象需求

由上述流程可以看出,实时气象资料数据库系统的监视对象至少包括2个方面:数据库系统运行监视和数据处理流程监视。

数据库系统运行监视包括数据库管理系统运行状态监视、空间监视和用户行为监视。重点包括底层的商用数据库的关键进程监视、表空间监视、CPU与磁盘利用率等系统资源监视。

数据流程监视包括来报数量统计、应到报缺报统计、未处理资料统计、数据入库统计、错报统计、处理进程状态监视、数据备份和清除监视。监控对象重点是对实时资料(地面、高空、国外数值预报产品等)入库情况、关键进程运行状态、数据处理临时目录文件积压状态、数据质量监测等,并提供各省入库详情的查询。

1.3.3 告警级别

监控系统根据关键性能指标(Key Performance Indicator,KPI)计算监控对象状态所处的风险值,由该值确定告警级别。系统将风险值分为5个级别(见表1),最终界面显示的告警级别则将5个级别归并为异常、警告、正常3个级别,用红、黄、绿不同颜色标识。

风险计算公式为:

F通常取一个线性函数集合,即在不同的定义域范围内选取不同的线性函数,以体现随着监控对象状态值在一定条件下不断上升,将导致风险值线性增长。通过与KPI的比较分析计算得到的风险值为一个数字,不同的取值范围决定了不同的风险级别,风险级别划分为5个等级:

表1 事件状态风险值级别

2 系统实现

2.1 监控系统架构设计及部署

系统的架构选择没有采用广泛的Brower/Server架构,而是采用Client/Server架构。关于“胖”、“瘦”客户端的优缺点争论由来已久。胖客户端的优势在于优良的客户体验以及可以离线操作,浏览器的优势在于易于部署管理,全部数据存储在服务器,不存在数据同步问题。事实上,现在胖客户端通过不同的技术革新已远不是过去传统意义上的胖客户端,例如Java的RCP[4-6]以及.NET平台上的Smart Client[7]解决方案都具有广泛成功案例。不存在任何情况下都能始终保持优势的唯一方案,方案选择更多依据实际需要。系统选择胖客户端主要基于如下考虑:

(1)首先最重要的一点,是希望利用客户端的资源为值班人员提供更加友善的用户体验。这样监控客户端既可充分使用客户端的硬件资源和软件资源,也可利用客户端本地存储能力。

(2)通过一个集中的服务器,客户端通过网络可以非常容易地实现部署和自动更新,不再出现传统胖客户端程序会出现的各客户端版本不同的情况。

(3)系统整体功能划分上,考虑客户端负责数据展现和人机交互,而服务器负责数据处理和业务逻辑。

图3为监控系统架构设计图。

在整个监控框架中,系统通过部署在各监控对象上的代理程序(agent)采集各种运行状况信息,形成标准化的XML格式监控原始数据,提交给上层的数据及规则处理层。该层获得原始数据后,再根据在客户端和服务器端始终保持一致的全局规则及处理策略,对原始数据经过基于统计、基于规则的关联分析后,形成监控展示信息及报警数据,以标准化的XML形式,通过HTTP协议传输给展示层。展示层对XML文件进行解析,根据客户端的显示配置文件,定制图形化展示各个监控对象的运行状况,并对异常情况进行声音报警。

采用agent方法的优势在于分布式部署方便灵活,扩充方便,并且不会对之前监控内容造成影响;另外,为便于系统整合,agent数量可以随意增减,每个监控对象可以用一个agent采集,也可多个监控对象由一个agent采集。

图3 实时库业务监控系统架构

2.2 通过策略配置来灵活地调整监控内容

对业务监控系统,必须支持对监控规则的灵活配置和调整,以应对加密观测和突发应急服务事件需要,因为这些情况下往往需要对部分规则进行调整,如地震期间对某些重点关心区域应到站入库情况格外关注,甚至要求必须规定时间内全部入库,对这些应到站的报警阈值就会调高已满足监控需要。

系统通过灵活的监控策略配置文件并建立一套系统的监控规则语法描述,实现规则驱动下的监控内容灵活调整功能。系统将XML格式作为策略配置文件基本格式,并参考气象行业元数据特点[8],制定出XML规范下的规则策略描述形式。数据库监控策略中需考虑的常见因素如提供者、数据库及表、响应方法、阈值、频率、时间及逻辑计算、规则属性及内容等,在配置文件中皆使用相应XML的标签项(Tag)和属性值定义表示。

当各种规则及监控参数变更时,通过XML中的标签项及属性值予以执行。

2.3 基于REST架构思想构建监控内容传输

系统通过HT TP协议向客户端返回XML格式监控数据结果。也就是说,监控结果作为一种服务器资源,可以简单用类似http://localhost/rdbcat/output/device/01这样形式的URI表示并获取,并且每一个会话都是无状态的,可重复使用URI访问监控结果资源。这一点上正好符合REST(Representational State Transfer)[9]架构思想,即利用简便易行的方式满足远程信息获取的需要。

REST方法引入的另一优势就是系统监控结果可以方便整合进入其他监控平台,因为外部平台获取系统监控结果资源的方法十分简单,采用URI访问即可获得监控结果(XML形式),然后按照XML描述规则解析内容即可完成整合。

系统监控结果没有采用一个大而全的形式表示,而是分而治之,依照监控对象的分类划分为资料入库、统计、设备、进程等多个XML文件,便于未来与其他系统整合时,外部系统仅提取所关心监控结果文件即可。

以下为资料入库状况的结果XML文件示例。

此外,为降低运维复杂度,系统还为一二线值班人员进行展示及功能的特殊功能设计,如集中告警及处理,自动远程升级,日志查询统计,各省未入库站点分省统计,要素异常值报警等。实时库监控系统客户端运行展示界面如图4所示。

图4 实时库业务监控系统界面

3 结束语

随着气象业务发展,对实时数据库进行有效服务监控越来越重要。一方面,随着数据库系统自身庞杂程度以及业务系统技术复杂度的提高,对整个系统基础架构维持良好状态的要求不断增强;另一方面,实时业务对实时数据库的业务依赖性逐步加深,实时库服务在业务供应方面所扮演的角色也变得日益重要。业务依赖性的直接结果是,任何服务故障都会很快被各级用户很快感受到,从而使其对气象部门对外服务能力产生严重影响。

实时库监控系统自2008年奥运会期间业务上线运行后,一直作为重要业务保障,提升气象信息部门在应对实时库突发故障事件时的响应能力,从而有力地支撑实时数据库系统的稳定运行。系统通过采用服务监控处理流程,能够不断改进监控方式以配合业务和技术变动,在发生服务事故时提高响应能力,从而降低对业务的影响。经过两年多业务实践的充分检验,监控系统部署灵活、运行稳定、界面友好、升级方便、运维简便,已成为数据服务方面的重要业务保障系统,实现了预期设计目标,并为未来信息中心建立统一的大运维监控平台奠定技术基础。

致谢:感谢国家气象信息中心沈文海、高华云、琚玲、刘媛媛、周峥嵘、杨昕等大力协助和支持,以及众多一线值班人员的业务应用反馈支持;感谢张小缨对系统后续业务发展方向上的重要建议。

[1] 沈文海,赵芳,高华云,等.国家级气象资料存储检索系统的建立[J].应用气象学报,2004,6.

[2] 赵芳,高峰.如何保障实时气象资料的管理[J].中国计算机报,2007.

[3] Baron Anthony,Pizzo Kathryn,Sarabosing Michael.Methods for service monitoring and control,US Application Publication,Publication No.US 2006/0064486 A1 published on 23-Mar-2006[EB/OL].http://ip.com/patapp/US20060064486.

[4] Rich Client Platform.[EB/OL].http://www.eclipse.org/rcp.

[5] Ed Burnette.SAS.Rich Client Tutorial Part[EB/OL].http://www.eclipse.org.

[6] Jeff McAffer,Jean-Michel Lemieux.Eclipse Rich Client Platform-Designing,Coding,and Packaging Java Applications[D].NY:Addison-Wesley Professional,2005.

[7] Smart Client Application Model and the.NET Framework 1.1,Microsoft[EB/OL].http:∥msdn.microsoft.com.

[8] 王国复,徐枫,吴增祥.气象元数据标准与信息发布技术研究[J].应用气象学报,2005,1.

[9] Roy Fielding.Architectural Styles and the Design of Network-based Software Architectures[D].University of California-Irvine,2000.