基于SSH协议的CMACast智能维护系统设计

韩超

摘要：让基于Java语言开发的维护程序，通过SSH2协议远程登入到CMACast接收服务器，实时检测当前CMACast资料接收业务的运行状态，形成系统运行进程、硬盘使用情况、FTP推送情况、卫星入锁情况、通道文件接收情况五个维度的运行参数，并利用这些状态参数对业务运行情况进行诊断，然后针对诊断结果远程对Linux服务器作出相应的操作，从而达到故障判断和故障处理自动化的目的。最后通过WebService技术将诊断结果实时推送给网页、手机等多端监控平台。

关键词：CMACast;SSH协议;自动维护;实时播报

中图分类号：TP311 文献标识码：A

文章编号：1009-3044（2019）31-0068-04

1背景

CMACast系统是中国气象局自2012年6月正式投入业务使用的新一代气象卫星广播系统，它是目前各地区气象局接收卫星气象数据的主要手段。CMACast接收服务器作为CMACast系统的重要一环，自然也成了各气象局网络维护工作的重要科目。全新架构下的CMACast卫星接收系统在数据接收速率和接收时效上都有了质的飞跃，就市级卫星小站而言，单日数据接收量可达250G，接收文件数量达267万个。这也意味着在接收服务器上，平均每分钟将产生1854个文件。所以对于网络维护人员来说，时间就是珍贵的气象数据，一旦CMACast系统发生故障，能否第一时间发现并排除将直接影响当天数据接收的完整性。设计一个能够自动监控CMACast运行状态，自动排除CMACast常见故障的维护系统，最大限度得保障卫星资料接收的完整性，对于CMACast系统的维护工作显得尤为重要。

2系统概述

CMACast数据接收服务的系统功能主要由Recv_daemon、MeidaRecv、FileFtp、CMACast四个进程来配合实现。其中Recv_daemon和MeidaRecv负责数据接收和生成，FileFtp负责数据推送，CMACast则负责系统运行状态的监测显示。CMA-Cast作为小站接收监控软件，整体基于C/S架构设计。软件开发者通过将系统运行和系统监控分离的方式，合理得将任务分配给了不同的系统进程，并通过较为直观的图形界面，分别从系统硬件和服务软件两个方面进行实时监测和展示。

由于其监控软件整体基于C/S架构设计的特点，所以在系统运行时，服务进程会对系统各项状态都留有较为完整的运行日志。这使得我们能够基于这种架构，重新设计C/S架构中的c端，通过查询Linux系统和服务进程留下的运行日志，诊断CMACast运行状态以便程序进行相应的自主维护操作。

3维护程序与接收服务器的远程交互

3.1远程登入系统

SSH（安全外壳协议）是Secure Shell的缩写，由IETF的网络小组（Network Working Group）所制定。SSH是建立在应用层基础上的安全协议，专为远程登人会话和其他网络服务提供安全性的协议。SSH作为一种安全可靠的通讯协议已被广泛应用于Liunx系统的远程登入管理上。

JSch是一个纯Java实现的第三方SSH2协议类库，项目地址为WrfirW.jcraft.com/jsch/，利用该类库可实现远程登入到CMA-Cast接收服务器并执行SHELL查询命令的功能。下载类库包并引入项目后，首先在项目里用代码初始化Sessionf远程登入会话），运行代码如下所示。

jSch=new JSch（）;

session=jsch.getSession（用户名，IP地址，端口）;

session.setPassword（密码）;

由于严格的SSH公钥检查会影响Java维护系统的自动化任务，所以在Session初始化完成后需要取消SSH公鑰检查。最后让Java检测远程登人CMACast服务器。运行代码如下所示。

session.setConfig（”StrictHostKeyChecking”，”no”）;

session.connect（登人超时时间）;

3.2执行命令和获取反馈

让监控程序通过SSH的22端口对远程服务器进行管理，是实现CMACast服务器智能维护的基础。它使我们不仅可以判断出正在发生的故障，还能让监控系统全面接管CMACast接收服务器，从而达到智能维护的目的。

远程执行命令并实时获取执行后的反馈，是监控程序全面接管服务器的关键点。通过让Java支持SSH2协议后，这一点并不难实现。首先用Session打开命令通道（channelExec），然后在新建的通道中运行setCommand（）来执行查询命令。因为ChannelExec命令通道支持shell的分隔符，所以可以像在本机上执行shell脚本一样，运用“;”和“I”等符号在一次查询中提交多个命令。最后在命令通道中用getlnputStream方法获取执行结果。运行代码如下所示。

ChannelExec channel=（channelExec）session.openChannel（"exec"）：

4维护逻辑设计与实现

4.1常见故障

CMACast接收服务器的主要功能是卫星资料接收和传递，因其特殊的功能定位，日常维护中时常会遇到三种常见的系统故障。首先是卫星入锁状态异常，故障表现为系统无法接收到新的卫星资料，同时监控界面显示“未入锁”状态。其次是硬盘剩余空间异常，当“sdbl”“sdb2”“sdb3”三个磁盘分区的空间使用量长时间停留在90%时，会造成硬盘空间异常。最后是FTP推送异常，具体表现为系统无法将资料通过ftp推送至数据存储服务器。

4.2日志系统

CMACast接收服务器内各个资料的运行流转主要依赖四个挂载点，分别是位于/dvbs2目录下的“sdbl”“sdb2”“sdb3”和“sdb4”，其中容量为62G名为“sdb4”的挂载点内存储着系统运行的各项日志。日志系统以天为单位形成记录文件，并采用在文件末尾逐条添加的方式实时更新系统的各项状态。有了系统日志的数据支持，我们便能够以此为依据，自行定制智能维护系统的程序逻辑。

4.3入锁故障

入锁故障常见于冬天降雪天气，卫星接收器的金属抛物面被积雪覆盖后，造成卫星信号无法反射到信号焦点处的高频头内，导致接收设备无法入锁。入锁异常除了受雨雪天气影响较大外，还可能受通讯电缆中断和高频头损坏等因素的影响。实际维护时，网络值班人员需要时刻注意CMACast监控界面的入锁状态显示，发现入锁异常后需要及时检查室外的卫星接收器。

在CMACast日志系统的运行逻辑方面，系统当前的入锁状态会以1分钟的频率，实时记录在“/dvbs2/sdb4/log/dvb”路径下，以“YYYYMMDD.log”命名的日志文件里。不同时次的数据以换行符为间隔，记录下形如“12：46：25 Y 95 8.0 0.000000E+046657”样式的数据。每个时次数据又以空格符为间隔，分别记录下时间、状态、信号强度、信噪比（Eb/No）、误码率和数据率6项卫星入锁参数。

在设计程序的维护逻辑时，首先需要判断“/dvbs2/sdb4/log/dvb”路径下是否已经生成了当天的入锁日志文件。让维护程序通过“LS”命令获取日志目录下所有日志文件的名称，从而判断是否包含当前日期的日志文件即可完成判断过程。在代码编写上，由于ChannelExec命令通道支持shell的分隔符，所以在Java中可以使用“/n”换行符来连接多条查询命令。把切换目录和文件名显示命令合并成一条语句后，代码可以用如下方式组织。

String cmd=”cd ∧ncd/dvbs2/sdb4/log/dvb∧nls/n”：String message=shell.exeeCommand（cmd）;

執行查询命令后，维护程序会获得由所有日志文件名称组成的字符串。最后判断该字符串中是否包含当前日期即可确定当前的CMACast日志系统是否正常工作。

在确定当天入锁日志正常生成之后，可以让维护程序以日志文件为依据，检测当前卫星的入锁状态。由于系统是在文件尾部逐条添加状态参数，所以可以用“tail-n”的命令，直接获取日志文件尾部的最新状态信息。程序可以重点监控时间和状态两项参数，当检测到日志生成异常或者卫星入锁异常时，可以通过短信或语音的方式及时通知网络管理员。

入锁故障检测逻辑如图1所示。

4.4磁盘清理故障

磁盘清理异常是日常工作中出现几率最高的故障之一。CMACast系统会依次在“sdbl”“sdb2”和“sdb3”三个路径下存储文件。当三个挂载点的空间使用率都达到90%左右时，CMA-Cast系统会选择清空其中一个文件系统后继续储存文件。但是在日常工作中，磁盘清理功能时常会无法正确工作。这使得数据文件堆积达到设定阙值后无法被系统清空，导致新文件无法正常生成。在实际维护时，管理员通常需要手动重启操作系统。系统重启后一般能重新唤醒清理进程再次检查当前的磁盘状态，并执行相应的清理命令。

由于CMACast系统并未在日志文件内记录硬盘的使用状态，所以在设计程序的维护逻辑时，首先需要实时监控当前文件系统的使用情况。在维护程序远程打开CMACast系统的命令通道后，执行“dr-h”命令，即可获取形如图2的反馈数据。其中“/dev/sda5”“/dev/sda6”和“/dev/sda7”三个文件系统分别对应“/dvbs2/sdbl”“/dvbs2/sdb2”和“/dvbs2/sdb3”三个挂载点。正常状态下，当这三个挂载点的使用率达到90%时，CMACast系统会直接将对应的文件系统重新格式化。系统执行格式化命令的耗时很短，通常在1分钟以内。所以当我们以5分钟的间隔去定时检测系统硬盘时，如果累计两次都检测到三个文件系统使用率停留在90%，即可确定系统没能正常清理磁盘空间。

在检测到系统出现磁盘清理故障之后，需要让远端的维护程序代替CMACast进程，在SUSE系统中执行分区格式化的命令。在执行格式化命令之前，需要先终止CMACast相关进程使系统停止继续接收卫星数据。通过让维护程序执行“/home/cmacast/bin”目录下的“stopdaemon”脚本，即可在系统中停止Recv_daemon、MeidaRecv、FileFtp、CMACast四个进程。在CMACast停止接收数据之后，可让维护程序通过以下四步完成分区格式化的任务。首先通过执行“umount/dvbs2/sdbl”命令卸载“/dev/sda5”分区的挂载点“/dvbs2/sdbl”，然后让程序继续执行“mkfs.reiserfs/dev/sdb5”命令，将“/dev/sda5”分区重新格式化成reiserfs文件系统。待系统执行完毕后用“mount/dev/sda5/dvbs2/sdbl”命令将格式化后的文件系统重新挂载。最后执行“chown-R emacast：users/dvbs2/sdbl”命令将cmacast用户组添加到“/dvbs2/sdbl”。至此维护程序已通过命令行的方式，在远端完成磁盘清理任务。

磁盘分区被清空之后，维护程序需要重新运行“/home/cma-cast/bin/”路径下的start程序来恢复业务。由于维护程序和服务器之间的交互主要基于SSH协议来实现，远端无法显示系统的图形界面，这导致基于图形界面运行的CMACast监控程序无法被正常运行。想要在无人值守的状态下重新恢复业务，需要在SUSE系统中添加so库路径，以便维护程序能够绕过CMA-CAST监控程序，直接启动数据接收和ftp推送进程。通过在“/etc/ld.so.conf”系统文件中添加“/home/cmacast/lib/”路径即可完成CMACast系统的so库路径加载设置。此时在系统控制台输入“ldd/home/cmacast/bin/Recv_daemon”后可以查看Recv_dae-mOB、MeidaRecv、FileFtp三个进程所要调用的so库能否被系统正常加载。最后让维护程序远程提交“cd/home/cmacast/bin∧n./star/n./Recv_daemon＼n”命令，即可重新恢复卫星数据的接收和推送。

磁盘清理故障的检测逻辑如图3所示。

4.5FTP推送故障

数据文件推送是CMACast数据接收的最后一环，由进程“filenp”负责主要工作。当数据文件在本地成功生成后，会由“filefn）”进程推送至指定的FTP服务器。所以当文件无法及时被推送到数据存储服务器时，其故障可能由CMACast服务器或者FTP服务器异常导致。

在CMACast日志系统的运行逻辑方面，当有数据文件推送失败时，系统会实时记录下推送时间、推送失败原因以及文件完整路径三项内容，并以换行符为单项文件分隔标记，保存在路径“/dvbs2/sdb4/log/fileftp/error/fileftp/”下。日志文件以天为单位独立保存，当天的新记录在日志尾部逐条添加，其数据格式如图4所示。其中“[Thread.c 14531”括号内标识的“1453”为错误代码，不同的故障原因各对应不同的故障代码。

在设计维护程序的运行逻辑时，主要考虑检测FTP服务器和分析本地FTP推送日志两个方面。首先检测FTP服务器是否可用，让维护程序在远端用ftp协议登入资料存储服务器即可完成检测任务。当目标ftp服务器发生异常无法登入时，通过语音播报或手机短信的方式提醒管理员及时维护。在确定远端FTP服务器正常可用后，可继续分析CMACast的FTP推送状态。

FTP推送状态的检测分析可从两个方面着手，一方面是检测“fileftp”进程是否被正常运行。维护程序在远端提交“ps-A”命令后可获取包含CMACast服务器所有进程的反馈列表。分析反馈字符中是否包含“fileftp”关键词即可判断FTP推送进程是否被正常开启。如果推送进程未被正常开启，则CMACast服务器无法执行推送任务。另一方面是分析错误推送日志。让维护程序提交“cd/dvbs2/sdb4/log/fileftp/error/fileftpAnls＼n”命令，來获取“fileftp”进程生成的错误日志列表。由于系统以“YYYYMMDD.log”的格式来命名日志文件，所以当维护程序发现有当前日期的日志文件时，则进一步分析文件内容。

在冗长的日志文件中，维护程序主要提取三个方面的内容。首先是统计FTP推送错误的文件总数。由于系统用逐条添加的方式记录日志，所以让维护程序远程提交“we-l当前日期.log”命令来获取当前日志文件的总行数，即可得知错误文件的总数。第二是分析近期推送错误出现的频率。如果维护程序发现CMACast服务器在短时间内出现大量FTP推送错误时，则用语音或者短信的方式通知管理员及时维护。其代码组织逻辑是让维护程序在远端执行“cd/dvbs2/sdb4/log/fileftp/error/fileftp∧ntail-n 100当前日期.log”命令，以便截取当前日志的最后100条错误记录，格式如图5所示。在获取错误日志后，维护程序逐行分析错误推送的发生时间，并统计最近5分钟内所发生的错误次数。当统计值超过报警阙值时，维护程序将开始分析PrP推送出错的主要原因。维护程序要提取的第三项内容是近期出现频率最高的错误代码。不同的错误代码意味着不同的推送异常原因，分析并提炼出近期出现次数频率最高的故障代码，将对系统的维护工作有着重要的参考价值。在代码逻辑方面，利用统计第二项内容时所截取的部分日志，进一步统计各类错误代码出现的次数。错误代码以“Thread.c”为开始标识，以之后第一次出现的“1：”符号为结束标识，截取这两者间的字符串即可。通过对系统日志这三方面内容的提取和分析，维护程序不仅能够在FTP系统运行的过程中及时发现问题，还能归纳出错误原因供管理员参考。其程序逻辑如图5所示。

5通道文件的统计与监控

通道文件的接收状态被设计在CMACast监控程序的首页，在界面左侧占据着较大的版位。界面中时刻变化的接收文件数量，犹如心跳包一般，直接示意着当前系统的运行状态。在传统的维护工作中，通道组的文件接收状态只能通过电脑显示器进行监控，其监控方式和维护效率有很大的局限性。让维护程序通过SSH协议远程登入系统后，可以在无人值守的状态下实时查询各个通道组的文件接收状态，并借由WebService平台向手机、网站等多端推送。

在CMACast日志系统的运行逻辑方面，当相应的通道有数据文件被接收时，会在“/dvbs2/sdb4/log/chan/”路径下实时记录两类以“chan”字符开头的日志文件。分别是“log”结尾的完整接收文件日志和“err”结尾的未完整接收文件日志，其名称为“chan通道号YYYYMMDD”。日志记录仍以向文件尾部逐行添加的方式，记录每个文件的完整路径。

CMACast系统通过不同的通道组来分发各种类型的气象数据，不同的通道组由各种通道号组成，其分类与对应关系如图7所示。在设计维护程序的运行逻辑时，只需统计每个通道号对应日志文件的行数后相加汇总，即可完成各个通道组的文件接收状态提取。组织代码时，只要让维护程序向服务器提交“wc-1日志文件路径”命令后获取反馈，最后按照图6的分组方式汇总所有数据即可完成信息提取。

6执行效率评估

维护程序在远程登人CMACast服务器后，需要对系统进程、硬盘状态、CMACast运行日志进行统计和提取。虽然每次维护所涉及的资料达数百万行，但由于采用了文件行数统计和文件尾部资料提取等特殊的优化方法，使得程序整体的执行速度非常可观。为验证其执行效率，设定程序检测项目如图7所示，执行维护并作出反应的平均耗时为45秒左右。

7总结与讨论

维护程序通过SSH协议，可以远程提取CMACast接收服务器的各项运行状态。在程序分析各项运行参数的同时结合人工维护的一些经验，针对性得设计一系列智能维护逻辑，可以实现在无人值守的状态下自动处理大部分运行故障。维护程序在提取CMACast系统的各项运行状态后，通过数据库和WebService平台，可以实现向网页、手机等多端分发系统状态信息。

基于SSH协议的CMACast智能维护系统，通过对监控方式和维护手段的改进，打破了传统维护工作的各种局限，增加了发现问题的主动性，提高了工作效率，使得整个维护工作更加智能化。

[通联编辑：谢媛媛]