国产精品1024永久观看,大尺度欧美暖暖视频在线观看,亚洲宅男精品一区在线观看,欧美日韩一区二区三区视频,2021中文字幕在线观看

  • <option id="fbvk0"></option>
    1. <rt id="fbvk0"><tr id="fbvk0"></tr></rt>
      <center id="fbvk0"><optgroup id="fbvk0"></optgroup></center>
      <center id="fbvk0"></center>

      <li id="fbvk0"><abbr id="fbvk0"><dl id="fbvk0"></dl></abbr></li>

      一種檢測方法

      文檔序號:7601536閱讀:145來源:國知局
      專利名稱:一種檢測方法
      技術(shù)領(lǐng)域
      本發(fā)明涉及通信領(lǐng)域,尤其涉及一種基于自定義健康性檢測協(xié)議的檢測方法。
      背景技術(shù)
      互聯(lián)網(wǎng)的迅速發(fā)展出現(xiàn)了越來越多的網(wǎng)站,各行各業(yè)對服務(wù)器站點的可靠性要求越來越高,其中最基本最迫切的要求就是希望網(wǎng)站能夠穩(wěn)定運行不癱瘓,即使出現(xiàn)了異常事故也希望能夠在最短的時間內(nèi)恢復(fù)正常,友好地使用戶感覺不到服務(wù)器的振蕩。
      事實上對于一個網(wǎng)站而言,因為網(wǎng)站的服務(wù)器的運行涉及到很多方面的穩(wěn)定性,包括操作系統(tǒng)本身、應(yīng)用服務(wù)器容器、基本業(yè)務(wù)組件、外部通訊設(shè)備(比如數(shù)據(jù)庫服務(wù)器、短消息網(wǎng)關(guān)、短消息中心等等)長時間運行的結(jié)果肯定會趨向于服務(wù)器越來越不穩(wěn)定,最主要的比如CPU、內(nèi)存這些資源得不到調(diào)度的話,將會出現(xiàn)系統(tǒng)死機、服務(wù)器沒有響應(yīng)而癱瘓的結(jié)果。
      面對這些現(xiàn)實情況,如果我們?nèi)コ僮飨到y(tǒng)本身的影響、外部系統(tǒng)設(shè)備的影響,而只關(guān)注服務(wù)器應(yīng)用程序本身的話,目前現(xiàn)有的能夠保證系統(tǒng)穩(wěn)定性的技術(shù)大致有以下幾方面1、選擇一些商用的比較成熟的應(yīng)用服務(wù)器容器,比如IBM的WebSphere、BEA的WebLogic等等。
      2、通過性能測試保證應(yīng)用程序本身沒有內(nèi)存泄漏等常見問題。
      3、采用多結(jié)點的負載均衡方案。通過一個負載均衡設(shè)備,下掛多個站點服務(wù)器進行流量均擔;負載均衡設(shè)備負責服務(wù)器的健康性檢測,發(fā)現(xiàn)其中的某一臺服務(wù)器發(fā)生故障就將客戶流量轉(zhuǎn)移到其他健康的服務(wù)器上面,從而實現(xiàn)了不中斷業(yè)務(wù)而對用戶透明的功能。
      4、有人值守的服務(wù)器機房里面,發(fā)現(xiàn)系統(tǒng)癱瘓就立刻手工重新啟動。
      目前運用比較成熟廣泛的技術(shù)是依靠負載均衡設(shè)備進行多臺服務(wù)器的流量分擔,其中一臺服務(wù)器發(fā)生故障就將訪問流量轉(zhuǎn)移到其他服務(wù)器上面去,對用戶實現(xiàn)了屏蔽。
      主要的負載均衡設(shè)備供應(yīng)商有Cisco、Nortel(Alteon)、Foundry、Extreme、F5、中國的華為公司等。
      圖1是典型的負載方案組網(wǎng)圖,從圖1中可見,負載均衡設(shè)備放置在服務(wù)器前端,根據(jù)一定的負載均衡算法將用戶流量合理的分擔到各個內(nèi)容相同的服務(wù)器上面;對用戶來說感覺不到多結(jié)點的存在,就像在訪問同一臺服務(wù)器一樣。
      負載均衡設(shè)備模擬客戶端訪問、定時向服務(wù)器發(fā)出健康性檢測報文,以檢查服務(wù)器運行的健康狀況,一旦發(fā)現(xiàn)其中的某一臺服務(wù)器沒有響應(yīng)或者拒絕服務(wù),那么立即將用戶訪問流量轉(zhuǎn)移到其他正常的服務(wù)器上面去,保證了網(wǎng)站的可靠不間斷運行。
      但是很顯然,該技術(shù)存在明顯的缺點負載均衡方案需要相對較高的成本。
      以上示意圖只是單個負載均衡結(jié)點的組網(wǎng)方案,負載均衡設(shè)備同樣存在單點故障的隱患,因此更加可靠的組網(wǎng)方案需要兩臺負載均衡設(shè)備互為備份的進行組網(wǎng)。
      一臺負載均衡設(shè)備的價格一般在幾十萬左右,加上多臺負載分擔的服務(wù)器開銷,成本花費相對昂貴,大多用于可靠性要求很高不能間斷服務(wù)的商用網(wǎng)站。
      另外,負載均衡方案并不能自動重啟服務(wù)器,只能將用戶流量轉(zhuǎn)移到其他健康的服務(wù)器上面去;一旦所有的服務(wù)器都發(fā)生故障的話,將會使得整個網(wǎng)站癱瘓不能恢復(fù)。
      現(xiàn)有技術(shù)中,還存在一種超文本傳輸協(xié)議(HTTP Hypertext TransferProtocol)方式的健康性檢測(也就是大多數(shù)負載均衡設(shè)備實現(xiàn)的健康性檢測),但其只能通過判斷HTTP協(xié)議的應(yīng)答碼來判斷服務(wù)器的健康與否。比如HTTP協(xié)議規(guī)定服務(wù)器返回應(yīng)答碼200表示正常、返回應(yīng)答碼400以上表示服務(wù)器錯誤。但是在實際情況下,只是通過應(yīng)答碼還無法更加準確的判斷服務(wù)器的健康狀況。比如當服務(wù)器處理異常,顯示一個處理錯誤的頁面給用戶,同樣返回的應(yīng)答碼是200,但是實際上我們認為這個時候網(wǎng)站已經(jīng)無法正常的給用戶提供服務(wù)了,這個時候僅僅通過應(yīng)答碼是不能全面判斷服務(wù)器的正常與否的。

      發(fā)明內(nèi)容
      本發(fā)明的目的是提供一種對被檢測單元進行定時健康性檢測,有效的提高被檢測單元的可靠性與故障恢復(fù)能力的方法。為此,本發(fā)明采用如下技術(shù)方案一種檢測方法,其特征在于在協(xié)議中設(shè)置一檢測字段;當進行檢測時,包括以下步驟發(fā)送請求步驟檢測單元向被檢測單元發(fā)送檢測處理請求,該檢測處理請求攜帶有檢測字段和處理策略;檢測步驟被檢測單元根據(jù)處理策略,進行相應(yīng)的操作;應(yīng)答步驟被檢測單元將處理結(jié)果填充至檢測字段中發(fā)送給檢測單元;分析結(jié)果步驟檢測單元根據(jù)檢測字段內(nèi)容,判斷被檢測單元的健康狀況并進行相應(yīng)的操作。
      所述字段內(nèi)容包括檢測返回碼和檢測結(jié)果消息碼。
      所述檢測返回碼中包括檢測成功、檢測告警或檢測失敗等選擇內(nèi)容。
      所述的方法,該檢測為周期進行的。
      所述的處理策略,包括申請內(nèi)存、釋放內(nèi)存、寫操作、讀操作等。
      所述的發(fā)送請求步驟進一步包括根據(jù)配置文件內(nèi)容讀取初始化配置參數(shù),并設(shè)置檢測處理請求。
      所述的配置文件還包括服務(wù)器重新啟動的腳本命令文件,以使被檢測單元重新啟動。
      所述的分析結(jié)果步驟中,還包括根據(jù)被測服務(wù)器的健康狀況而選擇系統(tǒng)正常、系統(tǒng)告警和重啟系統(tǒng)等操作。
      所述的方法,還包括根據(jù)操作的結(jié)果,生成日志文件的步驟。
      所述的協(xié)議為超文本傳輸協(xié)議(HTTP Hypertext Transfer Protocol)。
      在目前各個廠商現(xiàn)有的健康性檢測技術(shù)的基礎(chǔ)上,通過本發(fā)明可以帶來以下幾方面額外的有益效果1、提供了用戶開放的健康性檢測接口,網(wǎng)站系統(tǒng)管理員可以根據(jù)自己系統(tǒng)的特點,按照本發(fā)明規(guī)定的協(xié)議方法,自定義健康性檢測成功與失敗的標準、自定義不同情況下健康性檢測的結(jié)果信息,可以更加靈活、更加深層次的檢測到服務(wù)器系統(tǒng)內(nèi)部的運行狀態(tài),根據(jù)不同的狀態(tài)及時通知系統(tǒng)管理員或者系統(tǒng)癱瘓就立即重啟系統(tǒng)。
      2、本發(fā)明提供了實現(xiàn)以上功能的完善而優(yōu)秀的設(shè)計框架和流程方案,并且經(jīng)過大規(guī)模模擬網(wǎng)上運行,可以保證系統(tǒng)運行的穩(wěn)定性與可靠性。
      3、本發(fā)明所提供的系統(tǒng)自動重啟功能可以徹底解決負載均衡方案所無法做到的故障恢復(fù)功能,可以使處于癱瘓狀態(tài)的服務(wù)器迅速恢復(fù)正常運行。


      圖1是現(xiàn)有技術(shù)中的一個負載均衡設(shè)計方案;圖2是本發(fā)明的流程示意圖;圖3是本發(fā)明實施例的一個示意圖;圖4是本發(fā)明實施例中可執(zhí)行文件的關(guān)聯(lián)示意圖;圖5是本發(fā)明實施例中主運行實體的控制流程示意圖;圖6是本發(fā)明實施例中檢測線程的流程示意圖。
      具體實施例方式
      下面結(jié)合說明書附圖來說明本發(fā)明的具體實施方式
      。在本實施例中,被檢測單元是一個服務(wù)器,通過自定義健康性檢測協(xié)議的檢測方法來檢測該服務(wù)器的健康狀況,并根據(jù)檢測結(jié)果進行相應(yīng)的操作。
      本實施例在HTTP協(xié)議中設(shè)置一檢測字段,該字段內(nèi)容包括檢測返回碼和檢測結(jié)果消息碼,如表1所示,是該檢測字段的具體內(nèi)容。
      表1HTTP字段

      從表1中可見,我們在HTTP協(xié)議的頭字段中自設(shè)置了一個專門用于健康性檢測的頭字段“Health-Check”,用來表示健康性檢測的結(jié)果。
      我們對該頭字段的內(nèi)容規(guī)定如下ResultCode=[檢測返回碼];ResultInfo=[檢測結(jié)果消息]。它由檢測返回碼和檢測結(jié)果消息兩部分組成。
      檢測返回碼的含義0表示檢測成功、1表示檢測告警、其他表示檢測失敗。
      檢測結(jié)果消息表示本次健康性檢測的結(jié)果信息,同檢測返回碼一起用于提示用戶本次檢測的具體情況。
      如圖2所示,是本實施例的流程示意圖,從圖中可見,具體包括以下步驟發(fā)送請求步驟檢測單元向被檢測單元發(fā)送檢測處理請求,該檢測處理請求攜帶有檢測字段和處理策略,該檢測字段即是前面設(shè)置好的字段,該處理策略可以是中請并釋放內(nèi)存等相關(guān)操作要求;檢測步驟被檢測單元根據(jù)處理策略,進行相應(yīng)的操作,被檢測單元根據(jù)該檢測處理請求中攜帶的處理策略進行相應(yīng)的操作;應(yīng)答步驟被檢測單元將處理結(jié)果填充至檢測字段中發(fā)送給檢測單元;分析結(jié)果步驟檢測單元根據(jù)檢測字段內(nèi)容,判斷被檢測單元的健康狀況并進行相應(yīng)的操作。
      本實施例中,WEB服務(wù)器程序只需要按照如上所述的健康性檢測協(xié)議添加HTTP頭字段就可以了。
      舉例來說,比如某一個網(wǎng)站采用本發(fā)明的方法監(jiān)控系統(tǒng)穩(wěn)定性,通過定時訪問http://localhost:8080/index.jsp這個頁面來檢測系統(tǒng)的健康狀況。服務(wù)器應(yīng)用程序可以在index.jsp中指定不同的處理策略來判斷本身的健康狀況,然后根據(jù)處理結(jié)果按照上面表格里面的協(xié)議格式填充Health-Check頭字段的返回碼和返回消息(例如可以在其中申請一塊內(nèi)存然后釋放內(nèi)存,如果成功則表明服務(wù)器健康,設(shè)置檢測成功應(yīng)答碼和成功消息;如果無法申請內(nèi)存則表明內(nèi)存泄漏檢測失敗,設(shè)置失敗應(yīng)答碼和失敗消息內(nèi)容,也可以指示被檢測服務(wù)器作讀操作或者寫操作等,根據(jù)操作結(jié)果進行判斷。)。通過分析這個自定義頭字段的內(nèi)容來判斷服務(wù)器的健康狀況,進而按照不同的策略來進行告警或重啟系統(tǒng)等操作。
      通過這種方式可以由用戶靈活的定制各種服務(wù)器健康與否的標準,從而擺脫了單一依靠HTTP本身的應(yīng)答碼來判斷服務(wù)器健康狀況的局限性。
      本實施例中,具體的頭字段設(shè)置方法可以很簡單的在JSP文件中按照如下所示來設(shè)置&lt;%response.setHeader(″Health-Check″,result);%&gt;
      其中的result為本協(xié)議規(guī)定的固定格式字符串。
      本發(fā)明的實現(xiàn)方法可以通過硬件來實現(xiàn),也可以通過軟件實現(xiàn),下面通過軟件實現(xiàn)來說明本發(fā)明的可實現(xiàn)性。如圖3所示,是本發(fā)明軟件實現(xiàn)方式的流程示意圖,從圖中可見,在軟件實現(xiàn)的技術(shù)方案中,將本實施例所體現(xiàn)的技術(shù)內(nèi)容設(shè)置一個軟件程序,這里稱為軟件狗(watchdog)程序。
      首先介紹一下本發(fā)明所生成的文件結(jié)構(gòu),一個完整獨立的軟件狗程序包括以下四個文件可執(zhí)行文件、配置文件、說明文件、日志文件,如表2所示是各文件的說明。
      表2

      同時在可執(zhí)行文件中,它是由表3所示的四個程序?qū)嶓w構(gòu)成的表3

      以上四個程序文件的主要關(guān)系如圖4所示如圖4所示,Main主要控制整個軟件狗的健康性檢測流程,循環(huán)調(diào)用軟件狗的方法來執(zhí)行各種控制動作;軟件狗主要封裝了各種控制方法,讓Main以及HeartBeatThread來調(diào)用,完成各種控制動作的執(zhí)行;HeartBeatThread運行一個獨立的線程,專門進行定時的健康性檢測,同時將檢測得到的結(jié)果傳遞給軟件狗來保存處理;RunThread的功能只是獲取子進程的輸出流,以便系統(tǒng)重啟以后能夠?qū)⒋蛴⌒畔⒅囟ㄏ虻杰浖返目刂婆_。因為當系統(tǒng)癱瘓重啟以后,原來的服務(wù)器應(yīng)用程序被軟件狗拉起來,進而成為了軟件狗的一個子進程,必須通過軟件狗捕獲這個子進程的輸出流才能將原先的服務(wù)器應(yīng)用程序的控制臺信息重定向打印到軟件狗的控制臺上面去顯示給管理員。
      下面我們描述Main主運行實體的控制流程設(shè)計方案,請看如圖5所示的Main主運行實體的控制流程示意圖對照圖5,軟件狗的Main主運行實體整個控制流程如下所述1、軟件狗程序一啟動就進入主運行實體。首先進行初始化工作,將所有的配置參數(shù)從配置文件中讀取并保存。這些配置參數(shù)是健康性檢測所必須的元素,如果用戶沒有配置都將會使用默認的值。主要的配置參數(shù)請參照表4所示表4


      2、初始化的同時將會創(chuàng)建一個獨立的健康性檢測線程HeartBeatThread,專門用來進行健康性檢測。然后主運行實體將會在那里一直等待而阻塞,直到HeartBeatThread線程檢測完畢來喚醒它;3、一旦HeartBeatThread線程檢測完畢,主運行實體被其喚醒,繼續(xù)調(diào)用軟件狗的方法來設(shè)置當前系統(tǒng)狀態(tài)。這個時候根據(jù)HeartBeatThread線程對本次檢測的結(jié)果,對照先前的檢測結(jié)果來判斷整個系統(tǒng)當前是ACTIVE或是DEAD或者ABNORMAL。ACTIVE表示系統(tǒng)正常、DEAD表示系統(tǒng)癱瘓、ABNORMAL表示本次檢測失敗,但是還沒有達到最大失敗次數(shù)的中間狀態(tài)。
      4、根據(jù)前面得出的當前系統(tǒng)狀態(tài),進一步對其判斷。如果系統(tǒng)狀態(tài)不是ACTIVE,那么將錯誤信息寫入日志進行告警,或者發(fā)送電子郵件提醒系統(tǒng)管理員;如果已經(jīng)達到DEAD狀態(tài),那么調(diào)用外部命令重啟系統(tǒng)、將重啟記錄寫入日志文件。系統(tǒng)重啟以后將會等待配置參數(shù)所描述的重啟等待時間間隔,這段時間軟件狗將不會進行任何健康性檢測動作。
      5、以上步驟執(zhí)行完成后,主運行實體繼續(xù)重復(fù)進入第2個步驟所描述的等待狀態(tài),等待HeartBeatThread線程將其喚醒來做下一次的健康性檢測結(jié)果判斷,如此不斷重復(fù)下去。
      下面我們來描述獨立的健康性檢測線程HeartBeatThread的設(shè)計流程方案,如圖6所示HeartBeatThread運行了一個獨立的線程(我們稱之為心跳線程),專門負責定時進行健康性檢測工作,最后將檢測結(jié)果保存到軟件狗中。整個線程掛在執(zhí)行死循環(huán)的run()方法上面,周期性的進行健康性檢測。具體執(zhí)行步驟請看如下描述1、首先等待定時檢測間隔時間,此時本線程處于sleep狀態(tài),默認間隔時間為10秒鐘。
      2、接著在軟件狗中設(shè)置本次檢測結(jié)果為失敗。只有當本次檢測成功的時候才再次設(shè)置檢測結(jié)果為成功,所以在此后的執(zhí)行過程中一旦發(fā)生任何異常退出都將認為本次檢測失敗。
      3、同服務(wù)器創(chuàng)建HTTP連接,這個過程包含整個HTTP請求應(yīng)答模式的全過程,可以通過JDK提供的網(wǎng)絡(luò)編程接口直接調(diào)用來完成。通過這個連接來完成核心的健康性檢測過程,請求的內(nèi)容是軟件狗初始化時從配置文件中讀取的URL(也就是watchdog/request-page的值)。如果連接成功則繼續(xù)下面的步驟解析應(yīng)答報文;如果連接失敗則重試3次,全部失敗的話才直接退出,設(shè)置本次檢測結(jié)果為失敗。這個連接的過程還需要將先前的檢測所得到的會話ID作為Cookie的值跟隨請求一起發(fā)送到服務(wù)器端,目的是使得每次請求都是用同一個會話ID,避免服務(wù)器端不斷創(chuàng)建新的健康性檢測會話ID而浪費內(nèi)存資源。
      4、如果是軟件狗第一次檢測服務(wù)器,那么服務(wù)器一般會隨著HTTP響應(yīng)附帶一個包含會話ID(sessionID)的Cookie,為了讓客戶端在下次繼續(xù)請求的時候同樣隨著請求一起附帶這個Cookie到服務(wù)器端而用來識別并保持會話的一致性。因此軟件狗將會在此時查找HTTP頭字段中所有Cookie的值,如果發(fā)現(xiàn)存在會話ID,那么將其保存下來,以便在上面步驟3中所說的將這個會話ID隨著下一次健康性檢測報文一起帶到服務(wù)器端來保持會話一致性。
      5、查找并解析自定義的HTTP頭字段“Health-Check”,取出自定義應(yīng)答碼“ResultCode”和自定義應(yīng)答結(jié)果信息“ResultInfo”。
      6、通過分析返回的應(yīng)答碼來判斷本次健康性檢測的結(jié)果。
      7、設(shè)置本次檢測結(jié)果以及檢測結(jié)果信息到軟件狗中。
      8、喚醒Main主線程來對本次檢測結(jié)果進行進一步處理。
      9、重復(fù)步驟1,等待間隔時間繼續(xù)準備進行下一次健康性檢測。
      本實施例中相關(guān)問題說明1、在健康性檢測協(xié)議部分我們舉例了JSP中如何設(shè)置自定義的HTTP頭字段的值,同時在實際應(yīng)用中并不限于在JSP中進行,只要在應(yīng)用程序任何可以訪問HTTP應(yīng)答的地方都可以設(shè)置這個自定義頭字段,這樣就給用戶提供了非常方便靈活的健康性檢測定制空間。
      2、本發(fā)明側(cè)重于描述自定義健康性檢測協(xié)議的設(shè)置與實現(xiàn),提供了自定義健康性檢測明確的用戶接口描述。本發(fā)明同樣支持并兼容基于HTTP應(yīng)答碼的健康性檢測判斷標準。如果用戶希望使用傳統(tǒng)的HTTP應(yīng)答碼方式來檢測自己的網(wǎng)站系統(tǒng)的話,同樣只需要修改配置文件,關(guān)閉自定義健康性檢測協(xié)議開關(guān),配置表示服務(wù)器正常的應(yīng)答碼范圍以及標志服務(wù)器失敗的應(yīng)答碼范圍就可以了。
      3、所有使用本發(fā)明的網(wǎng)站服務(wù)器程序最好都要提供一個能夠讓服務(wù)器重新啟動的腳本命令,以便在服務(wù)器癱瘓的時候能讓軟件狗找到如何重啟該服務(wù)。這個腳本命令需要在配置文件中的watchdog/cmd-str結(jié)點進行配置。
      4、本發(fā)明的軟件狗和網(wǎng)站服務(wù)器應(yīng)用程序運行在同一臺服務(wù)器之上,操作系統(tǒng)不限。但是如果用戶不需要重新啟動網(wǎng)站服務(wù),而只需要對遠程服務(wù)器進行告警記錄以及電子郵件提醒的話,同樣可以用于監(jiān)控任何一臺遠程服務(wù)器。
      5、健康性檢測線程HeartBeatThread的執(zhí)行流程中3、4兩個步驟中說明的會話ID的獲取和保存技術(shù)也可以實現(xiàn)可配置。如果用戶希望每次檢測使用同一個會話的話,可以將其配置成會話保持開關(guān)打開;如果用戶希望通過不同的會話來檢測系統(tǒng)的話,也可以配置成會話保持開關(guān)關(guān)閉。因此軟件狗提供了靈活的會話保持機制。
      以上僅是本發(fā)明的幾種具體實現(xiàn)方式而已,然而,本發(fā)明的保護范圍并不局限于此,所有根據(jù)該種原理設(shè)計的方案,都應(yīng)在本發(fā)明的保護范圍內(nèi)。
      權(quán)利要求
      1.一種檢測方法,其特征在于在協(xié)議中設(shè)置一檢測字段;當進行檢測時,包括以下步驟發(fā)送請求步驟檢測單元向被檢測單元發(fā)送檢測處理請求,該檢測處理請求攜帶有檢測字段和處理策略;檢測步驟被檢測單元根據(jù)處理策略,進行相應(yīng)的操作;應(yīng)答步驟被檢測單元將處理結(jié)果填充至檢測字段中發(fā)送給檢測單元;分析結(jié)果步驟檢測單元根據(jù)檢測字段內(nèi)容,判斷被檢測單元的健康狀況并進行相應(yīng)的操作。
      2.如權(quán)利要求1所述的方法,其特征在于所述的字段內(nèi)容包括檢測返回碼和檢測結(jié)果消息碼。
      3.如權(quán)利要求1所述的方法,其特征在于所述檢測返回碼中包括檢測成功、檢測告警或檢測失敗選擇內(nèi)容。
      4.如權(quán)利要求1所述的方法,其特征在于該檢測為周期進行的。
      5.如權(quán)利要求1所述的方法,其特征在于所述的處理策略,包括申請內(nèi)存、釋放內(nèi)存、寫操作、讀操作等。
      6.如權(quán)利要求1所述的方法,其特征在于所述的發(fā)送請求步驟進一步包括根據(jù)配置文件內(nèi)容讀取初始化配置參數(shù),并設(shè)置檢測處理請求。
      7.如權(quán)利要求6所述的方法,其特征在于所述的配置文件還包括服務(wù)器重新啟動的腳本命令文件,以使被檢測單元重新啟動。
      8.如權(quán)利要求1所述的方法,其特征在于所述的分析結(jié)果步驟中,還包括根據(jù)被測服務(wù)器的健康狀況而選擇系統(tǒng)正常、系統(tǒng)告警和重啟系統(tǒng)操作。
      9.如權(quán)利要求1所述的方法,其特征在于還包括根據(jù)操作的結(jié)果,生成日志文件的步驟。
      10.如權(quán)利要求1所述的方法,其特征在于所述的協(xié)議為超文本傳輸協(xié)議(HTTP Hypertext Transfer Protocol)。
      全文摘要
      本發(fā)明涉及一種檢測方法,其特征在于在HTTP協(xié)議中設(shè)置一檢測字段,該字段內(nèi)容包括檢測返回碼和檢測結(jié)果消息碼;當進行檢測時,包括發(fā)送請求步驟檢測單元向被檢測單元發(fā)送檢測處理請求,該檢測處理請求攜帶有檢測字段和處理策略;檢測步驟被檢測單元根據(jù)處理策略,進行相應(yīng)的操作;應(yīng)答步驟被檢測單元將處理結(jié)果填充至檢測字段中發(fā)送給檢測單元;分析結(jié)果步驟檢測單元根據(jù)檢測字段內(nèi)容,判斷被檢測單元的健康狀況并進行相應(yīng)的操作。本發(fā)明可以更加靈活、更加深層次的檢測到服務(wù)器系統(tǒng)內(nèi)部的運行狀態(tài),根據(jù)不同的狀態(tài)及時通知系統(tǒng)管理員或者系統(tǒng)癱瘓就立即重啟系統(tǒng)。
      文檔編號H04L29/06GK1791034SQ20041010406
      公開日2006年6月21日 申請日期2004年12月13日 優(yōu)先權(quán)日2004年12月13日
      發(fā)明者張磊, 龔華, 錢劍 申請人:華為技術(shù)有限公司
      網(wǎng)友詢問留言 已有0條留言
      • 還沒有人留言評論。精彩留言會獲得點贊!
      1