本發明屬于計算機領域,特別涉及一種用于監控目標系統的自動化運行維護監測系統。
背景技術:
目前絕大多數目標系統主要依賴于手動操作且無法實現自動化的實時監控系統,因此,全自動化的監控平臺和實用的數據展示及分析界面具有很重要的意義。多數據源多平臺分布式數據采集技術面臨很多技術問題,首先,從目標系統各節點所有設備中采集系統運行數據,這些數據涉及到諸如CPU,內存、磁盤狀態主機基本信息,也涉及到nfds、tomcat等應用狀態、還涉及到各服務器、各防火墻之間的連通性,如何開發有效的數據采集技術,將分布式環境下各種信息采集并統一匯集到中心節點提供進一步分析和呈現是個難點。其次,多節點數據傳輸可靠性、實時性(低延遲)、安全性,比較將多個節點上采集到的數據實時匯入到中心節點,考慮在不同的網絡環境下(可直連至中心節點,需要經過中間機跳轉),不同的數據格式(日志型、浮點型等)、不同的匯聚頻率(秒級,分鐘級、小時級等),不同的傳輸模式(上行數據、下行數據)的背景下。第三,多業務數據分析,目標系統運行情況監測需要涉及系統運行數據、目標系統數據、系統資源使用情況數據,這些數據最終都會匯聚到中心節點,如何針對已經收到的數據進行有效的統計分析,包括按小時、天、周、月的統計報表,待監測系統的整體健康情況指標,系統各項監控指標的關聯性分析等,考慮到目標系統監控系統所要分析的數據較多,如何對日益增長的數據進行有效分析給出系統的綜合狀態判斷,并能進一步夠挖掘數據的內部規律,甚至預先判斷出系統可能出問題的時間點和問題方向,從被動運維轉變成主動運維。
技術實現要素:
為了解決上述技術問題,本發明提供一種自動化運行維護監測系統,包括數據采集系統、數據發布系統、UI子系統,
所述數據采集系統包括系統運行情況監測模塊組、業務數據監測模塊組、配置管理模塊組、系統輔助模塊組、數據服務模塊組,
所述系統運行情況監測模塊組包括服務器資源監測模塊、應用服務監測模塊、設備連通性監測模塊、網速流量監測模塊、系統資源監測模塊、網絡鏈路監測模塊,所述業務數據監測模塊組包括數據入庫模塊、數據查詢模塊、穩定度計算模塊、穩定度告警模塊、穩定度排名模塊,所述配置管理模塊組包括指標管理模塊、主機管理模塊、模板管理模塊、行為管理模塊、事件管理模塊、告警配置模塊,所述系統輔助模塊組包括電話記錄模塊、發布通知模塊,所述數據服務模塊組包括數據管理模塊、對外接口模塊、統計分析模塊。
本發明的自動化運行維護監測系統,其中數據發布系統為分布式消息隊列系統,所述分布式消息隊列系統可將多條消息加到一個消息集合中發布,不創建單獨的緩存,使用所述目標系統的頁面緩存;發布者順序發布,訂閱者通常比發布者滯后時間,減少了緩存管理及垃圾收集的開銷。
優選的本發明服務器資源監測模塊包括文件系統使用率監測單元、CPU使用率監測單元、主機存活時間監測單元、內存使用率監測單元、內存總量監測單元、交換分區使用率監測單元、安全日志分析監測單元、日志分析監測單元、網卡狀態檢查監測單元、異常登錄系統事件監測單元、磁盤讀寫監測單元;
優選的本發明應用服務監測模塊包括監測目標系統的所有應用程序和服務,包括:nfs服務單元、tomcat服務單元、ssh服務單元、oracle服務單元、MstoreNode服務單元、IndexerServer服務單元、QuorumPeerMain服務單元;
優選的本發明設備連通性監測模塊能夠對目標系統硬件設備(包括服務器、交換機)實時監控連通性,支持故障告警;對于頻繁出現故障的設備,提出預警,便于預測和評估硬件及軟件情況;監測目標系統防火墻上各端口狀態,包括:去往各節點的端口、連接目標系統核心交換機的端口,并能支持故障告警;能夠監控目標系統核心交換機上的各端口狀態、數據庫對象狀態、異常IP連接、ASM狀態、數據庫備份情況等監測;
本發明網絡流量監測模塊可以監控各網關服務器到加載機傳輸速率,將每日傳輸速率入庫,便于日后分析統計,支持告警;
本發明網絡鏈路監測模塊包括監測各節點目標系統到各網關服務器鏈路連通性。
本發明的數據入庫模塊每日將前一日各節點上報的基礎數據入庫,以便按不同條件查詢或使用;
本發明的數據查詢模塊能提供按不同條件查詢,并將查詢結果以曲線和表格顯示,且支持excel導出;查詢條件包括能按節點數據;能按日、周、月、年分別查詢各節點的基礎數據;能查詢每日數據總量;能按日、周、月、年分別查詢各節點的數據總量;
本發明的穩定度計算模塊能夠實現每日定時對各數據穩定度和穩定區間的計算和更新,以便判斷每日上報數據是否正常;
本發明的穩定度告警模塊每日數據以曲線和表格形式展開、支持Excel導出,并根據穩定區間監控每日數據波動,低于穩定區間下限20%以上的數據則告警;
本發明的穩定度排名模塊實現對不同節點數據穩定性排名。
本發明的系統資源監測模塊,支持查看所有主機的磁盤每周各天的使用量和使用率;支持統計查看每周所有節點主機磁盤變化量最高的前幾臺服務器磁盤變化信息。
本發明的告警配置模塊支持針對任務定制告警目標用戶、告警條件和告警方式,在滿足告警條件時向選定的所有告警目標用戶通過選定的告警方式及時發出告警;所述告警包括暫停告警、恢復報警、對每日上報數據超出閥值進行告警;所述告警的延遲不小于5分鐘;
告警方式至少支持電話通知、短信通知和Email通知三種方式;三種方式的緊急程度依次降低;電話通知是指向選定用戶撥打電話,僅用于需緊急趕赴現場處理的情況;短信通知的緊急程度次之,短信內容包括必要的信息概述;Email通知緊急程度最低,郵件內容應盡量詳實;
告警目標用戶默認是當前用戶,至少應有一位告警目標用戶,可根據需要額外添加;
暫停告警可以防止系統批量變更或機房變遷等長時間服務無法恢復的時候頻繁告警現象,暫停告警后,暫停的告警項不會顯示在巡檢告警欄里;
恢復告警將暫停告警項恢復,進行正常告警;
業務數據告警對每日上報數據超出閥值進行告警,閥值通過三個月內歷史值去畸求得平均值后得出。
本發明的電話記錄模塊針對各用戶的來電咨詢記錄,方便為日后出現相似問題提供參考,包括來電時間、問題反饋、單位名稱、問題點處理流程、問題反饋說明等記錄,可增、刪、改、查各相關記錄;
發布通知模塊可方便值班人員之間值班事宜的溝通和了解,通知在公告欄中顯示,可以增加、刪除、編輯通知。
本發明的自動化運行維護監測系統,其中UI子系統,提供實用、友好的用戶界面,可以通過可視化接口進行數據查詢和維護,并能按需求以周報、月報、年報的形式導出表格;包括:
實時數據展示單元:要求可以動態的數據的變化曲線圖,優選的是上報數據量,不同的數據類型通過不同的曲線的顏色加以區分展示在圖表上,可以選擇展示某一種數據類型曲線;
歷史數據展示單元:要求可以查看所有歷史數據和選擇指定日期的歷史數據,默認為前一天的歷史數據,展示的圖表要求可以縮放歷史查看范圍;
比較數據展示單元:要求將各節點之間相同類型的數據進行比較展示,以柱狀圖的形式展示出來,從而可以直觀的看出各節點之間的業務數據繁忙情況;
查詢數據展示單元:要求針對部分節點上報數據以表格形式展示出來,可以帶搜索功能,分頁顯示;
告警數據展示單元:要求告警信息分類別在界面左下角匯總展示,有告警的時候加以顏色提醒,當點擊具體告警項時,通過彈窗的方式將告警信息分組展示出來;支持確認、暫停、恢復指定的告警項。
本發明還提供了一種自動化運行維護監測方法,所述數據采集系統采集目標系統的通用指標項數據和相關業務指標項數據,并將數據主動推送給各區域中心節點的分布式系統代理服務器,所述分布式系統代理服務器統一將數據匯聚到中心分布式系統服務器,所述中心分布式系統服務器將數據統一入庫,簡單統計分析系統將結果統計入庫到統計分析庫中。
具體的闡述本發明的方法,包括系統運行情況監測步驟、業務數據監測步驟、系統資源監測步驟,
所述系統運行情況監測方法包括如下步驟:
1)在插件管理中啟動,服務器資源插件,各種應用插件,網絡、設備連通性插件;
2)啟動命令下發至各服務器插件管理進程;
3)插件管理進程為插件分配資源,啟動插件;
4)插件開始周期性采集信息;
5)插件將采集到的信息發送給插件管理進程;
6)插件管理進程周期性的將收集到的插件采集信息發送到區域中心匯集節點;
7)中心匯聚節點周期性的從各區域中心節點拉取采集信息并入庫;
8)系統管理程序根據收到的信息周期性啟動統計分析程序,定期統計;
9)用戶查看監控信息。
所述業務數據監測方法如下:
1)在插件管理中啟動業務數據采集插件;如果已經啟動,轉2)
2)業務采集插件周期性向XX系統讀取業務數據;業務數據采集不需要將插件下發至各節點服務器,只要在中心及誒單通過XX系統接口讀取所需數據即可;
3)業務數據入庫;按照本系統的存儲格式將讀到的數據量信息入庫;
4)系統針對各節點數據,執行穩定度評估算法;一般情況下只要選擇一種評估算法即可,必要情況下,可以更改算法,更改法不影響整體流程;
5)計算結果入庫;
6)用戶查看穩定度排名。
所述系統資源監測步驟還包括:
1)在插件管理中啟動,磁盤信息采集插件;
2)啟動命令下發至各服務器插件管理進程;
3)插件管理進程為插件分配資源,啟動插件;
4)插件開始周期性采集信息;
5)插件將采集到的信息發送給插件管理進程;
6)插件管理進程周期性的將收集到的插件采集信息發送到匯集節點;
7)中心匯聚節點周期性的從各分區域中心節點拉取采集信息并入庫;
8)系統管理程序啟動統計分析程序,統計出磁盤使率變化曲線;
9)用戶查看磁盤使用率和TOPN變化量。
本發明的有益效果在于,自動化運行維護監測系統是對整個目標系統的運行情況進行全方位的監測保障系統,是為有效做好目標系統維護工作、掌握系統運行情況、提供系統異常的告警信息而建設的平臺。系統要能夠實現全自動化的實時監控、能夠實現數據的實時統計與分析,且能夠清晰醒目的展示數據的變化,便于數據分析和問題改進。
附圖說明
圖1.實施例1的自動化運行維護監測系統整體示意圖;
圖2.實施例1的數據采集系統示意圖;
圖3.實施例3的服務器資源監測模塊示意圖;
圖4.實施例4的應用服務監測模塊示意圖;
圖5.實施例5的UI子系統示意圖;
圖6.實施例6的自動化運行維護監測方法示意圖。
具體實施方式
實施例1
如圖1所示,實施例1的自動化運行維護監測系統1整體上包括數據采集系統2、數據發布系統3、UI子系統4。結合圖2所示,數據采集系統包括系統運行情況監測模塊組5、業務數據監測模塊組6、配置管理模塊組7、系統輔助模塊組8、數據服務模塊組9。系統運行情況監測模塊組5包括服務器資源監測模塊10、應用服務監測模塊11、設備連通性監測模塊12、網速流量監測模塊13、系統資源監測模塊14、網絡鏈路監測模塊49。業務數據監測模塊組6包括數據入庫模塊15、數據查詢模塊16、穩定度計算模塊17、穩定度告警模塊18、穩定度排名模塊19。配置管理模塊組7包括指標管理模塊20、主機管理模塊21、模板管理模塊22、行為管理模塊23、事件管理模塊24、告警配置模塊25。系統輔助模塊組8包括電話記錄模塊26、發布通知模塊27。數據服務模塊組9包括數據管理模塊28、對外接口模塊29、統計分析模塊30。
其中設備連通性監測模塊12能夠對目標系統硬件設備(包括服務器、交換機)實時監控連通性,支持故障告警;對于頻繁出現故障的設備,提出預警,便于預測和評估硬件及軟件情況;監測目標系統防火墻上各端口狀態,包括:去往各節點的端口、連接目標系統核心交換機的端口,并能支持故障告警;能夠監控目標系統核心交換機上的各端口狀態、數據庫對象狀態、異常IP連接、ASM狀態、數據庫備份情況等監測;
網絡流量監測模塊13可以監控各網關服務器到加載機傳輸速率,將每日傳輸速率入庫,便于日后分析統計,支持告警;
網絡鏈路監測模塊49包括監測各節點目標系統到各網關服務器鏈路連通性。
數據入庫模塊15每日將前一日各節點上報的基礎數據入庫,以便按不同條件查詢或使用;
數據查詢模塊16能提供按不同條件查詢,并將查詢結果以曲線和表格顯示,且支持excel導出;查詢條件包括能按節點數據;能按日、周、月、年分別查詢各節點的基礎數據;能查詢每日數據總量;能按日、周、月、年分別查詢各節點的數據總量;
穩定度計算模塊17能夠實現每日定時對各數據穩定度和穩定區間的計算和更新,以便判斷每日上報數據是否正常;
穩定度告警模塊18每日數據以曲線和表格形式展開、支持Excel導出,并根據穩定區間監控每日數據波動,低于穩定區間下限20%以上的數據則告警;
穩定度排名模塊19實現對不同節點數據穩定性排名。
系統資源監測模塊14,支持查看所有主機的磁盤每周各天的使用量和使用率;支持統計查看每周所有節點主機磁盤變化量最高的前幾臺服務器磁盤變化信息。
告警配置模塊25支持針對任務定制告警目標用戶、告警條件和告警方式,在滿足告警條件時向選定的所有告警目標用戶通過選定的告警方式及時發出告警;所述告警包括暫停告警、恢復報警、對每日上報數據超出閥值進行告警;所述告警的延遲不小于5分鐘;
告警方式至少支持電話通知、短信通知和Email通知三種方式;三種方式的緊急程度依次降低;電話通知是指向選定用戶撥打電話,僅用于需緊急趕赴現場處理的情況;短信通知的緊急程度次之,短信內容包括必要的信息概述;Email通知緊急程度最低,郵件內容應盡量詳實;
告警目標用戶默認是當前用戶,至少應有一位告警目標用戶,可根據需要額外添加;
暫停告警可以防止系統批量變更或機房變遷等長時間服務無法恢復的時候頻繁告警現象,暫停告警后,暫停的告警項不會顯示在巡檢告警欄里;
恢復告警將暫停告警項恢復,進行正常告警;
業務數據告警對每日上報數據超出閥值進行告警,閥值通過三個月內歷史值去畸求得平均值后得出。
電話記錄模塊26針對各用戶的來電咨詢記錄,方便為日后出現相似問題提供參考,包括來電時間、問題反饋、單位名稱、問題點處理流程、問題反饋說明等記錄,可增、刪、改、查各相關記錄;
發布通知模塊27可方便值班人員之間值班事宜的溝通和了解,通知在公告欄中顯示,可以增加、刪除、編輯通知。
實施例2本實施例的改進在于自動化運行維護監測系統的數據發布系統3,即為分布式消息隊列系統,分布式消息隊列系統可將多條消息加到一個消息集合中發布,不創建單獨的緩存,使用所述目標系統的頁面緩存;發布者順序發布,訂閱者通常比發布者滯后時間,減少了緩存管理及垃圾收集的開銷。
實施例3本實施例與實施例1基本相同,如圖3所示,所不同的是服務器資源監測模塊10包括文件系統使用率監測單元31、CPU使用率監測單元32、主機存活時間監測單元33、內存使用率監測單元34、內存總量監測單元35、交換分區使用率監測單元36、安全日志分析監測單元37、日志分析監測單元38、網卡狀態檢查監測單元39、異常登錄系統事件監測單元40、磁盤讀寫監測單元41;
實施例4本實施例與實施例1基本相同,如圖4所示,所不同的是應用服務監測模塊11包括監測目標系統的所有應用程序和服務,包括:nfs服務單元42、tomcat服務單元43、ssh服務單元44、oracle服務單元45、MstoreNode服務單元46、IndexerServer服務單元47、QuorumPeerMain服務單元48。
實施例5本實施例與實施例1基本相同,如圖5所示,所不同的是,所述UI子系統4,提供實用、友好的用戶界面,可以通過可視化接口進行數據查詢和維護,并能按需求以周報、月報、年報的形式導出表格;包括:
實時數據展示單元50:要求可以動態的數據的變化曲線圖,優選的是上報數據量,不同的數據類型通過不同的曲線的顏色加以區分展示在圖表上,可以選擇展示某一種數據類型曲線;
歷史數據展示單元51:要求可以查看所有歷史數據和選擇指定日期的歷史數據,默認為前一天的歷史數據,展示的圖表要求可以縮放歷史查看范圍;
比較數據展示單元52:要求將各節點之間相同類型的數據進行比較展示,以柱狀圖的形式展示出來,從而可以直觀的看出各節點之間的業務數據繁忙情況;
查詢數據展示單元53:要求針對部分節點上報數據以表格形式展示出來,可以帶搜索功能,分頁顯示;
告警數據展示單元54:要求告警信息分類別在界面左下角匯總展示,有告警的時候加以顏色提醒,當點擊具體告警項時,通過彈窗的方式將告警信息分組展示出來;支持確認、暫停、恢復指定的告警項。
實施例6
結合圖6所示,本實施例提供了一種自動化運行維護監測方法,為滿足對XX系統全自動化運營維護的需求,采用微服務架構設計原理、系統被設計成由整合zabbix開源監控系統、mysql存儲系統、keepalive高可用系統、HBase大數據存儲系統、Spark分析系統及PHP/JSP頁面展示系統及簡單數據分析服務、大數據ETL服務、大數據統計分析服務等基礎服務有機組合的系統。每個子系統或服務對其它子系統或服務提供服務,運行監測UI子系統提供統一用戶界面。系統整體流程如下:部署到各區域中心節點的數據采集程序Agent采集到cpu、men、I/O、網絡等通用指標項和相關業務指標項,并將數據主動推送給各區域中心節點的ZabbixProxy,各區域中心節點ZabbixProxy統一將數據匯聚到XX中心ZabbixServer,ZabbixServer將數據統一入庫,簡單統計分析程序將結果統計入庫到統計分析庫中,UI子系統通過報表或eCharts框架展現數據。
下面按照系統的整體層次依次講述:
1)數據采集層:
數據采集終端采集到的所有數據用“指標”來定義,指標分為通用指標(如CPU指標、內存指標、I/O指標等)和專用指標(各種應用相關的指標),一般情況下指標由指標名、指標Key、指標類型、數據類型、指標值、采集周期等來定義。
各區域中心每臺計算機運行一個收集和發送監控數據的Zabbix Agent守護進程,Agent被設計成高度可擴展性的插件式結構,支持通用指標和專用指標采集。通用指標被Agent所默認實現,abbix內置了cpu、men、I/O、網絡等通用指標采集。專用指標通過shell或python腳本通過stdout來返回指定的指標值。在zabbix中專用指標為一組定義的UserParameter。系統在設計實現時需要考慮專用指標的設計、腳本實現、及部署。
在Agent端需要配置連接到Proxy地址或者ZabbixServer以定期將指標采集結果上報。需要配置指標集更新間斷時間,以決定多長時間從ZabbixServer更新新的指標集。
Zabbix框架支持以下指標類型:Agent、Java Manager Extension、SNMP、IMPI等。
考慮到自定義插件的升級部署、Agent客戶端的參數配置等。需要安裝自動化配置管理工具SaltStack,需要在主控節點上安裝salt-master和每一個受控節點上安裝salt-minion。
2)數據匯聚層:
各區域中心節點服務器采集到的數據可以先匯集到本分中心的zabbix proxy,再由區域中心節點的proxy再次匯集到中心節點zabbixserver,由XX中心zabbix入庫,也可以由各區域中心服務器直接匯集到中心節點zabbixserver。采集數據被設計成兩階段(區域中心節點和中心及節點)匯入機制,以支持數以千計的節點。
3)統計分析層
根據應用場景、分析深度的不同,可將統計分析分為簡單分析和大數據分析。
簡單分析
簡單分析主要應用于數據量小、批次小的統計、例如每小時的平均指標、最大指標等。簡單分析一般是增量分析、需要對實時采集到的監控數據進行匯總統計、可用存儲過程或JDBC在關系型數據庫中實現統計分析。l
大數據分析
在某些情況需要對數據進行全量分析、數據量多達10億級別,或者需要通過數據挖掘算法對數據進行特征值建模,并進行相應的關聯分析,例如研究CPU使用率、I/O負載情況和系統DOWN機或者某些日志錯誤之間的關聯性分析,此時就需要引入大數據分析技術。
現有的大數據分析技術通過兩個步驟完成:HBase數據存儲;Spark分析。某些基于大數據的分組查詢可以使用基于HBase的Impala來進行處理,需要建立獨立的ETL程序,來將監測數據加載、轉換、清洗至HBase,也需要建立分析程序,來調用Spark分析過程,并將分析結果寫入統計分析庫,以供UI層展示。
4)管理展示層
管理層負責將已經和庫的數據進行統計,加工、處理后以WEB形式呈現給前端,管理層會定義數據質量評估算法,定義數據基線,以及基于這些方法評價當前的數據質量。管理層對于需要告警的數據設置閥值,也對實時收到的數據進行告警處理。管理層會運行其它一此輔助功能:例如電話記錄、性能通知等。
基于匯聚層匯聚而來的監控數據,管理層在運行apache tomcat server上部署WEB服務。
實施例7
本實施例提供了一種自動化運行維護監測方法,所述包括系統運行情況監測步驟、業務數據監測步驟、系統資源監測步驟,所述系統運行情況監測方法包括如下步驟:
1)在插件管理中啟動,服務器資源插件,各種應用插件,網絡、設備連通性插件;
2)啟動命令下發至各服務器插件管理進程;
3)插件管理進程為插件分配資源,啟動插件;
4)插件開始周期性采集信息;
5)插件將采集到的信息發送給插件管理進程;
6)插件管理進程周期性的將收集到的插件采集信息發送到區域中心匯集節點;
7)中心匯聚節點周期性的從各區域中心節點拉取采集信息并入庫;
8)系統管理程序根據收到的信息周期性啟動統計分析程序,定期統計;
9)用戶查看監控信息。
所述業務數據監測方法如下:
1)在插件管理中啟動業務數據采集插件;如果已經啟動,轉2)
2)業務采集插件周期性向XX系統讀取業務數據;業務數據采集不需要將插件下發至各節點服務器,只要在中心及誒單通過XX系統接口讀取所需數據即可;
3)業務數據入庫;按照本系統的存儲格式將讀到的數據量信息入庫;
4)系統針對各節點數據,執行穩定度評估算法;一般情況下只要選擇一種評估算法即可,必要情況下,可以更改算法,更改法不影響整體流程;
5)計算結果入庫;
6)用戶查看穩定度排名。
所述系統資源監測步驟還包括:
1)在插件管理中啟動,磁盤信息采集插件;
2)啟動命令下發至各服務器插件管理進程;
3)插件管理進程為插件分配資源,啟動插件;
4)插件開始周期性采集信息;
5)插件將采集到的信息發送給插件管理進程;
6)插件管理進程周期性的將收集到的插件采集信息發送到匯集節點;
7)中心匯聚節點周期性的從各分區域中心節點拉取采集信息并入庫;
8)系統管理程序啟動統計分析程序,統計出磁盤使率變化曲線;
9)用戶查看磁盤使用率和TOPN變化量。
實施例8系統運行情況監測本實施例對XX系統所有服務器資源、應用服務、設備連通性、數據庫服務、網絡傳輸速度進行監測。
1)服務器資源監測:
監測主機的基本信息,包括:文件系統使用率、CPU使用率、主機存活時間、內存使用率、內存總量、交換分區使用率、secure日志分析、message日志分析、網卡狀態檢查、異常登錄系統事件、磁盤讀寫監測。
2)應用服務監測:
監測XX系統的所有應用程序和服務,包括:nfs服務、tomcat服務、ssh服務、oracle服務、MstoreNode服務、IndexerServer服務、QuorumPeerMain服務監測。
3)設備連通性監測:
能夠對XX系統硬件設備(包括服務器、交換機)實時監控連通性,支持故障告警;對于頻繁出現故障的設備,提出預警,便于預測和評估硬件及軟件情況;能夠監測XX防火墻上各端口狀態,包括:去往各節點的端口、連接XX核心交換機的端口等,并能支持故障告警;能夠監控XX核心交換機上的各端口狀態、數據庫對象狀態、異常IP連接、ASM狀態、數據庫備份情況等監測。
4)網絡傳輸速率監測:
監控各網關服務器到加載機傳輸速率,將每日傳輸速率入庫,便于日后分析統計,支持告警。
5)網絡鏈路監測:
監測各節點XX系統到各網關服務器(SMGG)鏈路連通性。以上所述實施例僅僅是本發明的優選實施方式進行描述,并非對本發明的范圍進行限定,在不脫離本發明設計精神的前提下,本領域普通技術人員對本發明的技術方案作出的各種變形和改進,均應落入本發明的權利要求書確定的保護范圍內。