基于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智能維護系統，通過對監控方式和維護手段的改進，打破了傳統維護工作的各種局限，增加了發現問題的主動性，提高了工作效率，使得整個維護工作更加智能化。

[通聯編輯：謝媛媛]