气象实时数据库服务监控系统设计与实现李德泉 何文春 阮宇智 刘一鸣（国家气象信息中心）摘要：实时数据库是气象信息部门针对预测预报及相关业务开发的重要数据服务系统，是确保从观测到预报业务流程按时高效完成的重要基础性数据支撑环境求。

本文介绍气象实时数据库业务监控系统的设计开发原则、架构设计，并针对服务监控的特点，分析了系统采用目前设计的优势、可扩展性，该系统综合考虑了实时数据库系统的设计与功能、性能特点，对入库情况、关键进程运行状态、商用关系数据库系统故障信息、入库流程、系统资源、数据质量监测等实时运行状态的展示，并提供各省入库详情的查询。

目前，该系统已稳定运行，提供日常服务，尤其在奥运会、国庆五十周年、亚运会等重大活动服务保障方面，取得良好业务保障效果。

关键词：实时数据库；服务监控；规则；值班报警1.引言实时气象资料数据库系统（以下称“实时数据库”或“实时库”）作为“国家级气象资料存储检索系统”(MDSS) [1]的重要组成部分，是气象信息部门针对预测预报及相关业务开发的重要数据服务系统，是确保从观测到预报业务流程按时高效完成的重要基础性数据支撑环境。

实时数据库系统对实时气象资料进行接收、分类、加工处理，并以地面气象资料、高空气象资料、海洋气象资料、气象辐射资料、农业气象资料、数值分析预报产品资料、气象灾害资料、气象卫星资料、气象服务产品资料和其他资料等十二类资料形式存储并实现资源共享。

并且，。

所谓实时（Real-Time），是指数据库应用系统一方面要维护大量共享数据和相关用户信息，另一方面其应用服务有很强的时间性，要求在一定的时刻或者一定的时间期限内从外部环境采集数据，经规范化处理后，以有效的数据组织形式存储，并及时响应随后的大量并发访问服务。

因此，整个数据处理过程具备短时、高效特点，并且每种资料对数据服务时效具有明确要求，过时则无意义[2]。

气象实时数据库不仅作为关键数据源连接气象中心、公共气象服务中心等部门的实时业务系统，还为科研用户提供一定时间期限内数据查询下载服务。

因其在整个业务流程中发挥关键的底层支撑作用，其服务稳定性及时效将直接影响其服务对象的实时业务效能和气象预报及时性与准确性，进而影响气象部门对内外行业用户、公众用户的气象服务质量，因此其从业务运行开始就一直作为国家气象信息中心的运维重点。

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

2.实时数据库监控系统设计思路2.1 基于服务监控系统的通用性设计作为针对实时气象数据库服务业务的监控系统，本系统核心设计目的是针对实时库的运算环境及健康状况进行即时监控与报警，确保实时数据服务能稳定支撑业务使用。

因此可归类为服务类监控系统（Service Monitoring and Control，SMC）[3]。

服务监控系统重点负责对信息服务系统运算环境及健康状况进行即时监控，动态显示服务成功或失败的可辨识特征，并对服务异常状况报警。

此外，服务监控还负责收集服务故障相关上下游运行环境及流程信息，进而协助使用部门改进 IT 服务质量。

服务监控系统往往以分布式方式采集来自于信息服务系统各相关设备、应用程序的日志信息和告警事件信息，判断服务故障事件，快速定位故障事件的来源，分析故障发生的根本原因，集中展示信息服务系统运算环境及整体安全状况。

一旦发现高风险服务故障事件还可触发相应故障事件处理流程，督促值班人员及相关责任人进行快速排查问题和解决故障。

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

整体架构示意图如下：图1. 服务监控系统体系架构信息基础层为整个系统提供基础设备及软件运行环境（网络设备、安全设备、业务系统、服务器等），其同时也是各类监控信息的数据获取来源。

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

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

展示层：实现整个服务监控系统的灵活展示和配置管理。

通过丰富的、多元化、分层次的图形化展示方式呈现各个监控对象的运行状况，提供有效的安全预警，减免严重故障的发生，快速应对突发故障并降低所造成的损失。

总之，一个设计良好的面向服务的监控系统应该至少具备如下完整因素：明确的监控对象，涵盖所有业务需要关注的场景并提示给使用者简明清晰必要信息，监控信息明确分类并具有界面友好的处理建议，当然，其他方面诸如快速部署、扩展性、标准化等根据实际需求也必须有所侧重。

同时，与之匹配的业务运维架构尤其是监控流程和运维岗位设置等管理性内容也会对监控系统设计及发挥效益起着至关重要的先决制约作用。

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

值班运维业务架构采用一线、二线两个级别。

一线值班并报告故障内容，二线值班负责排查并去除故障，之后反馈一线。

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

2.3 基于气象实时业务数据处理通用流程的设计需求2.3.1 典型的实时数据库业务数据流程实时库作为本系统的监视对象，其流程直接影响本系统的监视内容的设计，下以图2典型的实时业务流程进行简要分析说明。

此流程中，报文数据首先进行入库前预处理，报文经过格式检查并解析后按照分类归并，再存放于一定目录组织形式的临时文件库中，格式检查错误信息被写入日志。

入库处理进程从临时文件库中提取数据并存入关系型数据库或文件库中，期间经过质量控制算法发现的异常值写入要素异常值日志。

对外服务平台从数据库中提取信息，以程序接口、文件推送、查询服务等多种形式对外提供实时数据服务。

2.3.2 监控对象需求由上述流程可以看出，实时气象资料数据库系统的监视对象至少包括2个方面：数据库系统的监视和数据处理流程监视。

数据库系统的监视包括数据库管理系统运行状态监视、空间监视和用户行为监视。

数据流程监视包括来报数量统计、应到报缺报统计、未处理资料统计、数据入库统计、错报统计、处理进程状态监视、数据备份和清除监视。

2.3.3 告警级别监控系统根据关键性能指标（Key Performance Indicator，KPI）计算监控对象状态所处的风险值，由该值确定告警级别。

本系统将风险值分为5个级别（见表1），最终界面显示的告警级别则将5个级别归并为异常、警告、正常三个级别，用红、黄、绿不同颜色标识。

风险计算公式为：风险值＝F(监控对象状态，KPI) （1） F通常取一个线性函数集合，即在不同的定义域范围内选取不同的线性函数，以体现随着监控对象状态值在一定条件下不断上升，将导致风险值线性增长。

通过与KPI的比较分析计算得到的风险值为一个数字，不同的取值范围决定了不同的风险级别，风险级别划分为5个等级：表1. 事件状态风险值级别等级符号对应的典型故障状况取值范围告警级别5 VH（很高）故障风险很高，导致系统受到非常严重影响的可能性很大100～1254 H（高） 故障风险高，导致系统受到严重影响的可能性较大75～99异常3 M（中） 故障风险中，导致系统受到影响的可能性较大 50～742 L（低） 故障风险低，导致系统受到影响的可能性较小 25～49警告 1 VL（很低）故障风险很低，导致系统受到影响的可能性很小0～24 正常3.系统实现3.1 监控系统架构设计及部署本系统的架构选择上并没有采用广泛的Brower/Server架构，而是采用Client/Server架构。

关于“胖”、“瘦”客户端的优缺点争论由来已久。

胖客户端的优势在于优良的客户体验以及可以离线操作，浏览器的优势在于易于部署管理，全部数据存储在服务器，不存在数据同步问题。

事实上，现在胖客户端通过不同的技术革新已远不是过去传统意义上的胖客户端，例如Java的RCP[4,5,6]以及.NET平台上的Smart Client[7]解决方案都具有广泛成功案例。

不存在任何情况下都能始终保持优势的唯一方案，方案选择更多依据实际需要。

本系统选择胖客户端主要基于如下考虑：1）首先最重要的一点，是希望利用客户端的资源为值班人员提供更加友善的用户体验。

这样监控客户端既可充分使用客户端的硬件资源和软件资源，也可利用客户端本地存储能力。

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

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

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

在整个监控框架中，系统通过部署在各监控对象上的代理程序（agent）来采集各种运行状况信息，形成标准化的XML格式监控原始数据，提交给上层的数据及规则处理层。

该层获得原始数据后，再根据在客户端和服务器端始终保持一致的全局规则及处理策略，对原始数据经过基于统计、基于规则的关联分析后，形成监控展示信息及报警数据，以标准化的XML形式，通过HTTP协议传输给展示层。

展示层对XML文件进行解析，根据客户端的显示配置文件，定制图形化展示各个监控对象的运行状况，并对异常情况进行声音报警。

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

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