气象数据全链路监控系统的设计与实现

吴贵义，贾宁远，张志坚，黄华栋

（广州市突发事件预警信息发布中心，广东广州 511430）

近年来随着气象业务不断发展，各种气象产品不断增加，气象数据存在数据量大、传输时效要求高、种类繁多、格式各异、交互应用频繁等特点，日积月累之下气象部门的数据传输及应用脉络错综复杂，一旦数据出现未及时更新的情况，业务人员经常要对不同的数据生成环节逐一排查，在此过程中可能需要登录多个不同的服务器、检查多个文件夹或不同的数据库表去定位异常，效率非常低下［1-2］。气象数据监控已在众多单位开展研究应用，国内气象工作者提出了许多监控的方法［3-5］，陈荣等［6］研究了对地面气象观测业务的监控方案，其研究重点在于对报文资料的监控；金圣宇［7］等重点介绍了全流程监控的技术方案，但未提出具体实现的方法。本研究提出了全链路气象数据监控系统的设计思路，能够根据气象数据传输和存储特性，通过不同的访问方式，快速定位数据更新异常的具体节点，并对该系统所采用的数据多样性特征校验和时效性校验结合的监控原理、数据链路构建功能的实现过程做进一步的介绍。

1 气象数据特点

气象数据大致上分为结构化和非结构化两种类型［8］，通常通过TCP、SMB、FTP、HTTP等方式进行传输，数据在更新、命名规则、资料传输方面均有一定规律特性。例如雷达图、云图等以图片格式存放的气象产品，一般都是按照年月日时分秒（如yyyyMMddhhmmss.png）的规则命名，更新频率为每6 min更新一次；自动站资料存放在数据库中，每5 min更新一次；广州短时预报产品，每一小时更新一次报文。各类业务系统在应用气象数据时，由于受到开发环境或技术要求的限制，经常会针对特定系统建立专属的应用数据库，因此同一种气象资料从生成、加工到应用会形成不同的数据链。

2 设计与实现

气象数据链是数据从生成到具体应用过程中，资料传输处理所形成的数据脉络。本研究介绍的全链路气象数据监控系统，其功能主要是结合气象数据的特征，通过系统后台对数据进行配置形成数据块，再利用可视化技术将数据块串联形成数据链进行监控，系统总体设计示意图如图1所示。

图1 系统总体设计示意图

该系统主要由两大功能模块组成，一是单节点数据标识模块，通过建立数据监控算法规则，对节点数据的多样性和时效性特征进行判断，判断该节点中存放数据的服务器IP地址、数据存储方式、数据格式、传输方式以及更新规律等，实现对数据的标识；二是数据链监控模块，采用WEB框架，利用jQuery组件库实现拖拽、SVG图形绘画等技术，将分散的数据节点进行连接，并通过线程池技术实现对数据链的并发判断监控。

2.1 单节点数据标识模块设计

1）数据多样性校验设计。

监控气象数据首先需获得该数据的格式、存储方式和访问方式。对于大部分结构化和非结构化气象数据而言，主要存放方式有数据库和文件形式存放两种，传输和访问方式主要是利用TCP、SMB、SSH、FTP、HTTP等协议。其中气象部门常用的Oracel、SQL Server、Mysql等数据库数据通过TCP协议访问；文件共享常利用SMB协议访问；SSH协议多用于Linux操作系统的文件数据访问；FTP协议用于FTP服务的文件数据访问；HTTP协议实现web接口数据访问，如目前常用的广东省气象局IDEA数据接口平台［9］。

针对结构化与非结构化的数据采用不同的访问规则，其中来自数据库的数据属于结构化数据，这类数据规范清晰，可针对数据生成时间、每次数据入库固定的行数进行有效监控。而以文件格式存储的非结构化数据，数据内容多样复杂，可针对文件修改时间、文件命名规则、文件大小进行监控分析，通过HTTP接口获取的数据则可以利用读取接口返回值的情况来判断，如空值规则、404错误规则等。数据多样性校验规则如表1所示。

2）数据时效性校验设计。

在日常业务应用中如果数据更新不及时，则可认为数据更新异常，数据时效性作为气象数据按时更新的重要指标参数，需具备判断不同更新规律的方式，气象产品以更新频率的规律来分类，可以分为实时更新的数据、周期性定时更新的数据、区间定时更新的数据。其中实时更新的数据是指数据实时产生，没有固定更新的时间和频次，如气象预警信息；周期性定时数据指数据按照一定时间周期定时产生，即每隔一段时间产生新的数据，如每5 min更新一次的自动站实况数据、每6 min更新一次的雷达图；区间定时数据指数据在指定时间段定时产生，如每小时更新一次短时预报（只要求每小时内更新一次，但不要求在具体时间点更新）。

在数据时效性判定算法中首先要判断数据类型，实时类型数据通过直接加载数据连接驱动获取实时气象数据；周期定时类型数据首先计算数据参数的时间格式，一般数据时间参数分为秒、分、时3种类型，再通过当前时间减去数据时效，计算得到最小的有效时间effecttime，最后从最小时间到当前时间循环遍历有效时间的数据是否存在，如果存在表明数据正常，否则更新异常；区间定时类型数据首先通过当前时间减去数据延迟获取数据有效时间，然后计算数据有效时间所在的数据区间范围，如果小于最小区间，则取前一天的最大区间作为最终有效时间，否则取有效时间所在的区间作为最终有效时间。算法流程如图2所示。

图2 数据时效性判定算法流程示意图

2.2 数据链监控模块实现

通过2.1节的设计实现了对单点数据特性的标记工作，再通过监控系统后台进行配置，将相关的数据节点串联，从而形成对数据链的监控。

系统在数据流后台配置中引入jQuery组件拖拽技术［10］、SVG图形绘画技术［11］来解决监控流程配置的问题［12］。用户可以按照具体数据的实际情况，先在后台定义多个数据节点，并配置各节点的监控信息，再利用拖拽控件将所创建数据节点关联起来，以此形成一条具体的数据链。 数据链包括数据的流程类型、流程名称、数据周期、数据分类、状态等流程属性，其中流程类型分为定时和随时两类，数据周期支持单个周期定时数据，时间单位为分钟和HH：mm格式的区间定时数据，多个区间用半角逗号隔开。流程节点包括TCP、SMB、FTP、HTTP、SSH 5类，通过拖拽的方式将左边菜单的节点添加到流程编辑框中，然后双击对应的节点，在节点属性对话框中输入相应的节点属性，最后用线条将各个节点前后相连形成数据流。

数据监控程序执行过程中，引入了Quartz开源框架［12］，实现多数据流程的并发执行，同时针对每个数据流程实现递归索引，依次检索每个数据节点的数据状态。数据监控程序为避免对系统资源和内存的过度使用，默认创建拥有10个线程的线程池，即最多有10个数据流同时被执行。监控程序首先将所有数据流添加到Jobs队列中，当线程池中存在空闲线程时，则将Jobs队列中的工作任务提交到线程池中执行。全链路监控时首先从数据流首节点开始检查数据正常情况，然后递归检查各个后缀节点正常情况，当检查发现某节点的服务连接或数据状态异常时，则数据流监控结束，其他后缀节点或还未检查到的节点均标注为数据异常，若所有节点均检查完毕且数据正常，则认为该数据链路正常。数据流节点监控流程如图3所示。

图3 数据流节点监控流程示意图

气象数据全链路监控系统的应用界面如图4所示。

3 监控系统性能测试及应用效果

3.1 性能测试

该系统在实际运行中会产生多条数据链的并行监控，多线程并发能力关系到系统的稳定性，因此多线程并发的性能测试显得十分重要。项目采用了GroboUtils开源工具包编写基于Junit多线程的并行测试用例，模拟将300组数据链（每组数据链的节点为3个）加载到任务队列中，并针对数据流的响应时间和执行时间、数据节点的启动时间和执行时间和故障节点发现时间等指标进行了测试。测试结果显示在300多组数据链并发监控的状态下，各类主要指标达到了预期效果，满足实际应用的需求，性能测试指标：数据流响应时间1.6 s、数据流执行时间56 s；数据节点启动时间20 s；数据节点执行时间12.3 s；故障节点发现时间33 s。

3.2 应用效果

用户利用该系统对每个数据节点进行监控配置之后，还能够对数据的监控链路按照业务范畴进行归类，形成专属于某个具体业务的监控。该系统能够满足多种常用气象产品的监控需求，目前该系统主要应用在广州天气网、广州气象数据共享网的资料监控中，持续为包括环保、应急、教育等15个部门提供数据保障服务，工作人员多次通过该系统快速定位异常数据节点，极大提高了数据维护的效率。

该系统能够快速定位气象数据更新异常的节点，极大缩短工作人员维护数据的时间，数据可通过后台进行配置，适合多种业务系统数据的集中监控，具有一定的推广意义。该系统在告警方面仍存在不足，无法向数据维护人员主动推送告警信息，后续将开发多渠道告警的功能，用户可按照数据的重要性划分告警等级，通过电话、微信、短信等不同渠道进行告警，进一步提高数据保障的及时性。