本發(fā)明涉及計算機領(lǐng)域，具體涉及一種線上服務的錯誤監(jiān)控方法、裝置和系統(tǒng)。

背景技術(shù)：

隨著網(wǎng)絡的發(fā)展，網(wǎng)絡資源也越來越多，很多服務都會布置在應用服務器上，供用戶終端訪問網(wǎng)絡資源。比如在線支付服務，在線視頻服務等。其中，一個服務可以理解為一個進程。當然，一個應用服務器可以布置一個或者多個服務。

然而，在實際應用中，線上服務可能出現(xiàn)很多錯誤，比如數(shù)據(jù)庫連接不上，頁面訪問緩慢等錯誤，如果不能夠及時發(fā)現(xiàn)線上服務的錯誤，然后進行及時處理，無法盡快恢復服務的正常，就會長時間影響用戶對該線上服務的訪問。

在先技術(shù)中，監(jiān)控服務器不斷獲取各個線上服務的錯誤信息，然后各個監(jiān)控用的客戶端不斷刷新頁面，以發(fā)送請求去獲取錯誤信息。該過程中，服務器要維護各個客戶端的狀態(tài)，如維護客戶端獲取到了哪一時刻的哪種類型錯誤信息的狀態(tài)，然后在該客戶端下次訪問時，將該時刻之后的相應類型的錯誤信息返回給客戶端，如此，服務器需要維護大量的狀態(tài)，占用相當多的資源，影響服務器性能。另外，對于客戶端來說，由于需要頻繁刷新頁面，對獲取到的新的錯誤信息進行再渲染，也會占用過多客戶端資源，在刷新到一定次數(shù)之后，會導致客戶端卡頓的現(xiàn)象，從而影響用戶對客戶端的使用。

技術(shù)實現(xiàn)要素：

鑒于上述問題，提出了本發(fā)明以便提供一種克服上述問題或者至少部分地解決上述問題的線上服務的錯誤監(jiān)控裝置和相應的線上服務的錯誤監(jiān)控方法。

依據(jù)本發(fā)明的一個方面，本發(fā)明公開了一種線上服務的錯誤監(jiān)控方法，包括：

獲取各個線上服務的實時的錯誤信息；

根據(jù)所述錯誤信息，向各第一訂閱者發(fā)送錯誤項目消息；

由所述第一訂閱者通過長連接將所述錯誤項目消息轉(zhuǎn)發(fā)給與所述訂閱者對應的客戶端；其中，所述客戶端根據(jù)所述錯誤項目消息進行渲染展示。

優(yōu)選地，在所述獲取各個線上服務的實時的錯誤信息之后，還包括：

根據(jù)所述錯誤信息，向各第二訂閱者的發(fā)送錯誤項目消息；所述第二訂閱者記錄第一時間周期內(nèi)各服務的錯誤項目消息。

優(yōu)選地，在根據(jù)所述錯誤信息，向各第二訂閱者的發(fā)送錯誤項目消息；所述第二訂閱者記錄第一時間周期內(nèi)各服務的錯誤項目消息之后，還包括：

判斷客戶端是否是初始與第一訂閱者進行長連接；如果客戶端是初始與第一訂閱者進行長連接，則所述第一訂閱者從所述第二訂閱者處獲取第一時間周期內(nèi)各服務的錯誤項目消息轉(zhuǎn)發(fā)給客戶端；所述客戶端將所述第一時間周期內(nèi)各服務的錯誤項目消息進行渲染展示。

優(yōu)選地，所述根據(jù)所述錯誤信息，向各第一訂閱者發(fā)送錯誤項目消息還包括：

針對所述錯誤信息進行計算，得到針對所述服務錯誤信息和/或所述服務下的具體事項錯誤信息的錯誤分值，并根據(jù)所述錯誤分值生成錯誤項目消息；

向各第一訂閱者發(fā)送錯誤項目消息。

優(yōu)選地，所述客戶端根據(jù)所述錯誤項目消息進行渲染展示包括：

所述客戶端按時間序列將所述錯誤項目消息渲染為圖形化的狀態(tài)圖。

優(yōu)選地，所述客戶端根據(jù)所述錯誤項目消息進行渲染展示包括：

所述客戶端根據(jù)所述錯誤項目消息中對應各服務的服務錯誤信息，優(yōu)先服務錯誤信息進行渲染展示；

當接收到對一服務錯誤消息的點擊操作，則將所述錯誤項目消息中對應所述服務的具體事項錯誤信息進行渲染展示。

優(yōu)選地，所述根據(jù)所述錯誤信息，向各第一訂閱者發(fā)送錯誤項目消息包括：

根據(jù)所述錯誤信息，生成錯誤項目消息并將所述錯誤項目消息放入zmq隊列；

將所述zmq隊列中的錯誤項目消息，發(fā)送給各第一訂閱者loadjs。

優(yōu)選地，所述長連接包括websocket連接。

依據(jù)本發(fā)明的另外一個方面，本發(fā)明還公開了一種線上服務的錯誤監(jiān)控裝置，包括：

錯誤信息獲取模塊，適于獲取各個線上服務的實時的錯誤信息；

錯誤項目消息發(fā)送模塊，適于根據(jù)所述錯誤信息，向各第一訂閱者發(fā)送錯誤項目消息；

轉(zhuǎn)發(fā)模塊，適于由所述第一訂閱者通過長連接將所述錯誤項目消息轉(zhuǎn)發(fā)給與所述訂閱者對應的客戶端；所述客戶端根據(jù)所述錯誤項目消息進行渲染展示。

優(yōu)選地，在誤信息獲取模塊之后，還包括：

訂閱記錄模塊，適于根據(jù)所述錯誤信息，向各第二訂閱者的發(fā)送錯誤項目消息；所述第二訂閱者記錄第一時間周期內(nèi)各服務的錯誤項目消息。

優(yōu)選地，在訂閱記錄模塊之后，還包括：

初始信息發(fā)送模塊，適于判斷客戶端是否是初始與第一訂閱者進行長連接；如果客戶端是初始與第一訂閱者進行長連接，則所述第一訂閱者從所述第二訂閱者處獲取第一時間周期內(nèi)各服務的錯誤項目消息轉(zhuǎn)發(fā)給客戶端；所述客戶端將所述第一時間周期內(nèi)各服務的錯誤項目消息進行渲染展示。

優(yōu)選地，所述錯誤項目消息發(fā)送模塊包括：

錯誤分值計算模塊，適于針對所述錯誤信息進行計算，得到針對所述服務錯誤信息和/或所述服務下的具體事項錯誤信息的錯誤分值，并根據(jù)所述錯誤分值生成錯誤項目消息；

第一發(fā)送模塊，適于向各第一訂閱者發(fā)送錯誤項目消息。

優(yōu)選地，所述客戶端包括：

第一展示模塊，適于所述客戶端按時間序列將所述錯誤項目消息渲染為圖形化的狀態(tài)圖。

優(yōu)選地，所述客戶端包括：

服務錯誤展示模塊，適于所述客戶端根據(jù)所述錯誤項目消息中對應各服務的服務錯誤信息，優(yōu)先服務錯誤信息進行渲染展示；

具體事項錯誤展示模塊，適于當接收到對一服務錯誤消息的點擊操作，則將所述錯誤項目消息中對應所述服務的具體事項錯誤信息進行渲染展示。

優(yōu)選地，所述錯誤項目消息發(fā)送模塊包括：

隊列放入模塊，適于根據(jù)所述錯誤信息，生成錯誤項目消息并將所述錯誤項目消息放入zmq隊列；

錯誤項目消息發(fā)送模塊，適于將所述zmq隊列中的錯誤項目消息，發(fā)送給各第一訂閱者loadjs。

優(yōu)選地，所述長連接為websocket連接。

依據(jù)本發(fā)明的另外一個方面，本發(fā)明還公開了一種線上服務的錯誤監(jiān)控系統(tǒng)，包括：

各個前端服務器、監(jiān)控服務器和各個客戶端；

每個前端服務器適于運行各種服務，并將各種服務的錯誤信息返回給監(jiān)控服務器；

所述監(jiān)控服務器包括：

錯誤信息獲取模塊，適于獲取各個線上服務的實時的錯誤信息；

錯誤項目消息發(fā)送模塊，適于根據(jù)所述錯誤信息，向各第一訂閱者發(fā)送錯誤項目消息；

轉(zhuǎn)發(fā)模塊，適于由所述第一訂閱者通過長連接將所述錯誤項目消息轉(zhuǎn)發(fā)給與所述訂閱者對應的客戶端；

每個客戶端適于，根據(jù)所述錯誤項目消息進行渲染展示。

依據(jù)本發(fā)明的另外一個方面，本發(fā)明還公開了一種設備，包括：

存儲器，適于存儲可執(zhí)行代碼；

處理器，適于執(zhí)行所述可執(zhí)行代碼；所述可執(zhí)行代碼執(zhí)行以下步驟的方 法：

獲取各個線上服務的實時的錯誤信息；

根據(jù)所述錯誤信息，向各第一訂閱者發(fā)送錯誤項目消息；

由所述第一訂閱者通過長連接將所述錯誤項目消息轉(zhuǎn)發(fā)給與所述訂閱者對應的客戶端；其中，所述客戶端根據(jù)所述錯誤項目消息進行渲染展示。

根據(jù)本發(fā)明的線上服務的錯誤監(jiān)控方法和裝置，可以從各個應用服務器獲取線上服務的錯誤信息，然后根據(jù)pub-sub(發(fā)布及訂閱)的方式，根據(jù)所述錯誤信息發(fā)布錯誤項目消息，然后將該錯誤項目消息發(fā)送給訂閱該錯誤項目消息的各個第一訂閱者，并且由于本發(fā)明的客戶端與第一訂閱者長連接，那么可再由第一訂閱者通過長連接轉(zhuǎn)發(fā)至與該第一訂閱者相應的客戶端，由此解決了監(jiān)控服務器側(cè)需要維護各個客戶端的狀態(tài)，導致服務器資源占用較多的問題，以及客戶端側(cè)需要頻繁刷新頁面以獲取新的錯誤信息，導致客戶端資源占用較多、使客戶端出現(xiàn)卡頓現(xiàn)象的問題，取得了使監(jiān)控服務器側(cè)不用維護各個客戶端的狀態(tài)即可推送錯誤項目消息，減少對監(jiān)控服務器的資源占用，以及使客戶端側(cè)不用頻繁刷新即可獲取到新的錯誤信息，減少對客戶端的資源占用的有益效果。

上述說明僅是本發(fā)明技術(shù)方案的概述，為了能夠更清楚了解本發(fā)明的技術(shù)手段，而可依照說明書的內(nèi)容予以實施，并且為了讓本發(fā)明的上述和其它目的、特征和優(yōu)點能夠更明顯易懂，以下特舉本發(fā)明的具體實施方式。

附圖說明

通過閱讀下文優(yōu)選實施方式的詳細描述，各種其他的優(yōu)點和益處對于本領(lǐng)域普通技術(shù)人員將變得清楚明了。附圖僅用于示出優(yōu)選實施方式的目的，而并不認為是對本發(fā)明的限制。而且在整個附圖中，用相同的參考符號表示相同的部件。在附圖中：

圖1示出了根據(jù)本發(fā)明一個實施例的一種線上服務的錯誤監(jiān)控方法的流程示意圖；

圖1a示出了根據(jù)本發(fā)明一個實施例的客戶端渲染示例；

圖2示出了根據(jù)本發(fā)明另一個實施例的一種線上服務的錯誤監(jiān)控方法的流程示意圖；

圖3示出了根據(jù)本發(fā)明另一個實施例的一種線上服務的錯誤監(jiān)控裝置的結(jié)構(gòu)示意圖；

圖4示出了根據(jù)本發(fā)明一個實施例的一種線上服務的錯誤監(jiān)控裝置的結(jié)構(gòu)示意圖；

圖5示出了根據(jù)本發(fā)明另一個實施例的一種線上服務的錯誤監(jiān)控系統(tǒng)的結(jié)構(gòu)示意圖；

圖6示出了根據(jù)本發(fā)明一個實施例的一種設備的結(jié)構(gòu)示意圖。

具體實施方式

下面將參照附圖更詳細地描述本公開的示例性實施例。雖然附圖中顯示了本公開的示例性實施例，然而應當理解，可以以各種形式實現(xiàn)本公開而不應被這里闡述的實施例所限制。相反，提供這些實施例是為了能夠更透徹地理解本公開，并且能夠?qū)⒈竟_的范圍完整的傳達給本領(lǐng)域的技術(shù)人員。

實施例一

參照圖1，其示出了本發(fā)明一種線上服務的錯誤監(jiān)控方法的流程示意圖，具體可以包括：

步驟110，獲取各個線上服務的實時的錯誤信息；

在本發(fā)明實施例中，前端存在各個應用服務器，每個應用服務器中布置了一個或幾個服務，然后這些應用服務器將這些服務上線，從而各個網(wǎng)絡中的用戶終端即可通過互聯(lián)網(wǎng)訪問這些服務。在前端服務器之后，本發(fā)明設置了監(jiān)控服務器，該監(jiān)控服務器可以獲取這些應用服務器中的線上服務的錯誤信息。然后監(jiān)控用的客戶端即可連接該監(jiān)控服務器。

在實際應用中，在前端的各個應用服務器中，可設置SDK(Software Development Kit,軟件開發(fā)工具包)，該SDK提供了向監(jiān)控服務器傳輸錯誤信息的接口。在線上服務運行的時候，當應用服務器監(jiān)控到其服務出現(xiàn)的某種錯誤信息，則可以調(diào)用相應接口將該錯誤信息傳輸給監(jiān)控服務器，從而監(jiān) 控服務器則獲取到了各個線上服務的實時的錯誤信息。

步驟120，根據(jù)所述錯誤信息，向各第一訂閱者發(fā)送錯誤項目消息；

在本發(fā)明實施例中，在監(jiān)控服務器中，可以將第一進程作為發(fā)布者，將另外的各個第二進程作為該發(fā)布者的第一訂閱者，每個第二進程就是一個第一訂閱者。

那么第一進程可以根據(jù)前述錯誤信息生成錯誤項目消息，并作為發(fā)布者發(fā)布該錯誤項目消息。其中，發(fā)布該錯誤項目消息時，可將該錯誤項目消息send(推送)給各個第一訂閱者，各個第一訂閱者則可以receive(接收)該錯誤項目消息。

當然，本發(fā)明實施例中，客戶端向監(jiān)控服務器發(fā)送連接請求時，監(jiān)控服務器則為其啟動第一訂閱者進程，該第一訂閱者進程訂閱第一進程的發(fā)布的錯誤項目消息，并且由該第一訂閱者負責與該客戶端進行通信。

可以理解，本發(fā)明所述步驟120之前，客戶端需要首先與第一訂閱者建立長連接。

優(yōu)選的，步驟120包括：

子步驟121，針對所述錯誤信息進行計算，得到針對所述服務錯誤信息和/或所述服務下的具體事項錯誤信息的錯誤分值，并根據(jù)所述錯誤分值生成錯誤項目消息。

在本發(fā)明實施例中，對于獲取到的錯誤信息，可以對其進行計算，針對所述服務和/或所述服務下的具體事項的錯誤分值。比如對于服務A，其在3秒內(nèi)出現(xiàn)了4種具體事項的錯誤，具體事項A出現(xiàn)了5次，具體事項B出現(xiàn)了100次，具體事項C出現(xiàn)了50次，具體事項D出現(xiàn)了1次，那么服務A的錯誤分值可以為5+100+50+1＝151，每個具體事項的分值可以為其出現(xiàn)的次數(shù)。當然，本發(fā)明實施例中還可加入其他參數(shù)對具體事項或者服務的分值進行計算，比如對于具體事項，其錯誤每次出現(xiàn)的時間長度，時間長度越長，分值越高，如服務的網(wǎng)頁訪問緩慢錯誤，如果用戶終端訪問的網(wǎng)頁a，服務4秒才返回網(wǎng)頁數(shù)據(jù)，則其錯誤分值可以加上4，如果服務10秒才返回網(wǎng)頁數(shù)據(jù)，則其錯誤分值可以加上10。

當然，服務的分值可以為具體事項分值的累加。

可以理解，具體的具體事項和服務的錯誤分值的計算規(guī)則，可以根據(jù)需要設置，本發(fā)明不對其加以限制。

然后，本發(fā)明實施例則可以對服務和/或具體事項的錯誤分值生成錯誤項目消息，該錯誤項目消息可以包括服務名和其錯誤分值，如{(服務A，錯誤分值251)；(服務B，錯誤分值600分)}，和/或服務名下的具體事項及其錯誤分值，如{(服務A：(具體事項A，錯誤分值5)，(具體事項B，錯誤分值100)，(具體事項C，錯誤分值50)，(具體事項D，錯誤分值1))；(服務B：(具體事項M，錯誤分值100))}。

當然，在實際應用中，對于沒有錯誤消息的服務和/或該服務下的具體事項，可以將其分值設為一個固定值，比如為0，也放入錯誤項目消息中。

子步驟122，向各第一訂閱者發(fā)送錯誤項目消息。

然后，即可將上述錯誤項目消息向各第一訂閱者推送。

優(yōu)選地，步驟120包括：

子步驟123，根據(jù)所述錯誤信息，生成錯誤項目消息并將所述錯誤項目消息放入zmq隊列。

在本發(fā)明實施例中，對于從應用服務器中獲取的各服務的錯誤信息，首先可針對其生成錯誤項目消息。

在實際應用中，可以將指定時間段的所有錯誤信息，統(tǒng)一生成錯誤項目消息。比如對3秒內(nèi)獲取的各個應用服務器的錯誤信息按時間序列進行整合，生成錯誤項目消息。進一步的如，從0秒開始，監(jiān)控服務器開始受到應用服務器發(fā)送的錯誤信息，那么到3秒時，監(jiān)控服務器將0-3秒收到的錯誤信息進行整合，生成錯誤項目消息；然后到6秒時，監(jiān)控服務器將3-6秒受到的錯誤信息進行整合，生成錯誤項目消息，以此類推。

然后，本發(fā)明實施例將錯誤項目消息放入zmq隊列中，zmq(ZeroMQ)是一個簡單好用的傳輸層，像框架一樣的一個socket library，他使得Socket編程更加簡單、簡潔和性能更高。是一個消息處理隊列庫，可在多個進程、內(nèi)核和主機盒之間彈性伸縮，其在Socket API之上做了一層封裝，將網(wǎng)絡 通訊、進程通訊和進程通訊抽象為統(tǒng)一的API接口。通過zmq可是實現(xiàn)一對多的pub-sub方式，一個發(fā)布者發(fā)布的消息可以推送給多個訂閱者。

在本發(fā)明實施例中各個第一訂閱者與zmq隊列可通過socket(套接字)連接。

子步驟124，將所述zmq隊列中的錯誤項目消息，發(fā)送給各第一訂閱者loadjs。

在本發(fā)明實施例中，第一訂閱者可以為loadjs，該loadjs可以實現(xiàn)websocket長連接，并且能以訂閱者的身份訂閱zmq隊列中的錯誤項目消息，還以中間者的身份，將獲得的錯誤項目消息轉(zhuǎn)發(fā)給客戶端。該loadjs提供了zmq的一個庫，可以執(zhí)行訂閱zmq隊列所在進程的操作，訂閱完成后可以提供一個端口，將其獲取到的錯誤項目消息放入該端口，然后通過該端口將錯誤項目消息轉(zhuǎn)發(fā)至客戶端。

在本發(fā)明實施例中，那么對于zmq隊列首部的錯誤項目消息，則可以發(fā)送給各個第一訂閱者。在實際應用中，監(jiān)控服務器的第一進程可以記錄在線的第一訂閱者的個數(shù)，然后將發(fā)布的錯誤項目消息推送給各個第一訂閱者時，如果在指定時間段內(nèi)比如5秒內(nèi)，無論是否所有第一訂閱者都接收到了該錯誤項目消息，該錯誤項目則可以從zmq隊列中移出，然后發(fā)布zmq隊列中的下一個錯誤項目消息。

步驟130，由所述第一訂閱者通過長連接將所述錯誤項目消息轉(zhuǎn)發(fā)給與所述訂閱者對應的客戶端；其中，所述客戶端根據(jù)所述錯誤項目消息進行渲染展示。

在本發(fā)明實施例中，第一訂閱者由監(jiān)控服務器維護，其負責與客戶端保持長連接，并且作為錯誤項目消息的訂閱者，其可以訂閱zmq隊列中的錯誤項目消息。

當監(jiān)控服務器第一進程根據(jù)錯誤消息生成錯誤項目消息后，則可以將該錯誤項目消息發(fā)送給第一訂閱者，第一訂閱者由于根據(jù)客戶端長連接，則可以直接將該錯誤項目消息發(fā)送給客戶端?？蛻舳藙t可根據(jù)所述錯誤項目消息進行渲染展示。

在本發(fā)明實施例中，所述客戶端可以為瀏覽器客戶端，錯誤項目消息則可以在瀏覽器客戶端的網(wǎng)頁中進行渲染展示。由于本發(fā)明實施例的客戶端與第一訂閱者以長連接的方式進行連接，客戶端的網(wǎng)頁不用刷新網(wǎng)頁接口即可獲取到錯誤項目消息，從而將其渲染到網(wǎng)頁中進行展示。

當然，在實際應用中，客戶端可以從該錯誤項目消息中提取錯誤信息，然后針對這些錯誤信息進行渲染。

優(yōu)選的，所述長連接包括websocket連接。

WebSocket長連接是HTML5(Hypertext Markup Language5，超文本標記語言5)一種新的協(xié)議，它實現(xiàn)了瀏覽器與服務器全雙工通信(full-duplex)。采用WebSocket長連接，瀏覽器和服務器只需要要做一個握手的動作，然后，瀏覽器和服務器之間就形成了一條快速通道。兩者之間就直接可以數(shù)據(jù)互相傳送。

優(yōu)選的，所述客戶端根據(jù)所述錯誤項目消息進行渲染展示包括：

子步驟131，所述客戶端按時間序列將所述錯誤項目消息渲染為圖形化的狀態(tài)圖。

在本發(fā)明實施例中，可以將新獲取的錯誤項目消息，在之前的錯誤項目消息之后以圖形化的狀態(tài)圖進行動態(tài)展示。那么既保留了之前的錯誤項目消息展示情況，又有最新的錯誤項目消息的展示情況，方便技術(shù)人員觀察服務的運行情況。

比如，當某個服務在一段時間內(nèi)的錯誤項目消息的曲線很平滑，如圖1a，該服務在t1時刻之前都是一條直線，在t1時刻之后，曲線突然開始上揚，那么說明該服務從t1時刻出現(xiàn)錯誤，技術(shù)人員則能很容易的觀察到什么時刻該服務出現(xiàn)問題，從而可以盡快的處理該服務的錯誤。

其中，圖1a中的橫軸為時間，縱軸為錯誤。當然縱軸可以為錯誤的錯誤分值。

當然，本發(fā)明實施例中，在同一個網(wǎng)頁中，可以同時展示各種服務的錯誤項目消息的狀態(tài)變化。

優(yōu)選的，所述客戶端根據(jù)所述錯誤項目消息進行渲染展示包括：

子步驟132，所述客戶端根據(jù)所述錯誤項目消息中對應各服務的服務錯誤信息，優(yōu)先服務錯誤信息進行渲染展示。

在本發(fā)明實施例中，錯誤項目消息可以同時包括針對服務的服務錯誤信息和針對該服務下的具體事項的具體事項錯誤信息。該服務錯誤信息可以為對應該服務的各個具體事項的具體事項錯誤信息的累加。

那么客戶端在收到錯誤項目消息之后，可以優(yōu)先從錯誤項目消息中提取服務錯誤信息進行渲染展示。然后對其中各服務的具體事項錯誤信息進行緩存。

子步驟133，當接收到對一服務錯誤消息的點擊操作，則將所述錯誤項目消息中對應所述服務的具體事項錯誤信息進行渲染展示。

當技術(shù)人員想查看某個服務的具體事項錯誤信息的狀態(tài)圖時，則可以點擊該服務錯誤消息的展示區(qū)域，客戶端則可以從緩存中提取該服務的具體事項錯誤信息進行渲染展示，截圖事項錯誤信息可以在彈出框中展示，也可在新的頁面中展示，也可以在當前頁面中展示。

在本發(fā)明實施例中，客戶端可以采用Higcharts工具對錯誤項目消息進行渲染。其中，Higcharts是兼容絕大多數(shù)瀏覽器的純js(javascript，腳本)圖表庫。

對于在先技術(shù)，對于錯誤信息，客戶端不斷刷新網(wǎng)頁，從而對監(jiān)控服務器發(fā)出HTTP(Hypertext transfer protocol，超文本傳輸協(xié)議)請求，以輪詢的方式從詢問服務器是否有新的錯誤信息，服務器如果有則返回錯誤信息，如果沒有則返回空。因而，對于客戶端來說，其可能發(fā)送了很多無用的請求，占用了帶寬，并且客戶端需要不斷刷新網(wǎng)頁以發(fā)送請求，其占用資源多，刷新到一定程度之后，可能造成客戶端卡頓的現(xiàn)象，影響用戶的使用。

當然，在實際應用中，如果客戶端斷開與第一訂閱者的長連接，則監(jiān)控服務器注銷該第一訂閱者，不在向該客戶端推送錯誤項目信息。

在先技術(shù)對于監(jiān)控服務器對于一個客戶端，需要維護該客戶端展示的各種服務狀態(tài)，如記錄哪些服務哪些錯誤信息發(fā)送給了客戶端。其監(jiān)控服務器的邏輯復雜，不易對系統(tǒng)維護，并且其系統(tǒng)維護的狀態(tài)數(shù)量龐大，占用資源 多，影響服務器性能。

相較于在先技術(shù)，本發(fā)明實施例的前述過程，監(jiān)控服務器采用pub-sub的方式，監(jiān)控服務器收集到錯誤信息后主動將對應錯誤信息的錯誤項目消息推送給第一訂閱者，然后再由第一訂閱者通過長連接轉(zhuǎn)發(fā)給客戶端。使客戶端被動接收錯誤項目消息，不用刷新網(wǎng)頁以主動發(fā)送HTTP請求去獲取錯誤項目消息，從而可以降低客戶端的資源占用，避免因頻繁刷新網(wǎng)頁去發(fā)送HTTP請求而產(chǎn)生的卡頓現(xiàn)象。也使服務器不用維護客戶端展示的各個服務的狀態(tài)，直接將錯誤項目消息推送給客戶端即可，邏輯簡單，方便系統(tǒng)維護，并且可以降低系統(tǒng)的資源占用。

實施例二

參照圖2，其示出了本發(fā)明一種線上服務的錯誤監(jiān)控方法的流程示意圖，具體可以包括：

步驟210，獲取各個線上服務的實時的錯誤信息。

步驟220，根據(jù)所述錯誤信息，向各第二訂閱者的發(fā)送錯誤項目消息；所述第二訂閱者記錄第一時間周期內(nèi)各服務的錯誤項目消息。

在本發(fā)明實施例中，在監(jiān)控服務器還可以設置一個的第三進程，該第三進程作為第二訂閱者以訂閱新出現(xiàn)的錯誤項目消息，其可以從監(jiān)控系統(tǒng)啟動時就啟動。然后，當監(jiān)控服務器的第一進程獲取到錯誤信息，并生成錯誤項目消息后，可以將錯誤項目消息推送給該第二訂閱者。然后第二訂閱者獲取到該項目消息后，即可通過redis進行記錄，其記錄第一時間周期內(nèi)的各個服務的錯誤項目消息，比如記錄最近10分鐘的錯誤項目消息。其中Redis是一個開源的使用ANSI C語言編寫、支持網(wǎng)絡、可基于內(nèi)存亦可持久化的日志型、Key-Value數(shù)據(jù)庫，并提供多種語言的API(Application Program Interface，應用程序接口)。

在實際應用中，上述錯誤項目消息會寫入zmq隊列中，然后從該zmq隊列中將錯誤項目消息推送給第二訂閱者。

步驟230，判斷客戶端是否是初始與第一訂閱者進行長連接；如果客戶 端是初始與第一訂閱者進行長連接，則進入步驟240；如果客戶端不是初始與第一訂閱者進行長連接，則進入步驟250；

步驟240，所述第一訂閱者從所述第二訂閱者處獲取第一時間周期內(nèi)各服務的錯誤項目消息轉(zhuǎn)發(fā)給客戶端；所述客戶端將所述第一時間周期內(nèi)各服務的錯誤項目消息進行渲染展示。

在本發(fā)明實施例中，當一個未連接的客戶端的連接請求發(fā)送到監(jiān)控服務器時，監(jiān)控服務器則可以為其加載一個第一訂閱者，如前述loadjs，然后由loadjs維護與該客戶端的長連接。而由于客戶端是初始連接到第一訂閱者，其還未收到過任何錯誤項目消息，為了方便技術(shù)人員觀看錯誤項目消息的狀態(tài)，本發(fā)明實施例則第一訂閱者可以獲取當前初始鏈接時刻之前的第一時間周期內(nèi)的錯誤項目消息，再將其轉(zhuǎn)發(fā)給客戶端。該客戶端將所述第一時間周期內(nèi)各服務的錯誤項目消息進行渲染展示

比如客戶端A初始接入的時刻為12:00:00，那么客戶端A對應的第一訂閱者A，可以從第二訂閱者的記錄中獲取11:50:00-12:00:00內(nèi)的錯誤項目消息，然后將該一系列的錯誤項目消息轉(zhuǎn)發(fā)給客戶端A。那么客戶端A即可11:50:00-12:00:00內(nèi)的錯誤項目消息渲染為各服務的錯誤狀態(tài)圖。

當然，如果客戶端不是初始與第一訂閱者進行長連接，則客戶端已經(jīng)獲取過錯誤項目消息，只需要最新的錯誤項目消息即可。那么可以直接進入步驟250，通步驟250獲取最新的錯誤項目消息。

步驟250，根據(jù)所述錯誤信息，向各第一訂閱者發(fā)送錯誤項目消息。

步驟260，由所述第一訂閱者通過長連接將所述錯誤項目消息轉(zhuǎn)發(fā)給與所述訂閱者對應的客戶端；其中，所述客戶端根據(jù)所述錯誤項目消息進行渲染展示。

本發(fā)明實施例中，監(jiān)控服務器采用pub-sub的方式，監(jiān)控服務器收集到錯誤信息后主動將對應錯誤信息的錯誤項目消息推送給第一訂閱者，然后再由第一訂閱者通過長連接轉(zhuǎn)發(fā)給客戶端。使客戶端被動接收錯誤項目消息，不用刷新網(wǎng)頁以主動發(fā)送HTTP請求去獲取錯誤項目消息，從而可以降低客戶端的資源占用，避免因頻繁刷新網(wǎng)頁去發(fā)送HTTP請求而產(chǎn)生的卡頓現(xiàn)象。 也使服務器不用維護客戶端展示的各個服務的狀態(tài)，直接將錯誤項目消息推送給客戶端即可，邏輯簡單，方便系統(tǒng)維護，并且可以降低系統(tǒng)的資源占用。

再者，對于初始接入第一訂閱者的客戶端，可以由第一訂閱者從第二訂閱者的記錄中獲取最近一個第一時間周期內(nèi)的監(jiān)控服務器中的所有錯誤項目消息，并將其轉(zhuǎn)發(fā)給該客戶端，客戶端對這些錯誤項目消息進行展示后，可以使其可以在歷史錯誤消息的狀態(tài)圖的基礎(chǔ)上，動態(tài)的展示各服務的新的錯誤信息，方便技術(shù)人員觀察。

實施例三

參照圖3，其示出了本發(fā)明實施例的一種線上服務的錯誤監(jiān)控裝置的結(jié)構(gòu)示意圖，具體可以包括：

錯誤信息獲取模塊310，適于獲取各個線上服務的實時的錯誤信息；

錯誤項目消息發(fā)送模塊320，適于根據(jù)所述錯誤信息，向各第一訂閱者發(fā)送錯誤項目消息；

轉(zhuǎn)發(fā)模塊330，適于由所述第一訂閱者通過長連接將所述錯誤項目消息轉(zhuǎn)發(fā)給與所述訂閱者對應的客戶端；所述客戶端根據(jù)所述錯誤項目消息進行渲染展示。

優(yōu)選地，在誤信息獲取模塊310之后，還包括：

訂閱記錄模塊，適于根據(jù)所述錯誤信息，向各第二訂閱者的發(fā)送錯誤項目消息；所述第二訂閱者記錄第一時間周期內(nèi)各服務的錯誤項目消息。

優(yōu)選地，在訂閱記錄模塊之后，還包括：

初始信息發(fā)送模塊，適于判斷客戶端是否是初始與第一訂閱者進行長連接；如果客戶端是初始與第一訂閱者進行長連接，則所述第一訂閱者從所述第二訂閱者處獲取第一時間周期內(nèi)各服務的錯誤項目消息轉(zhuǎn)發(fā)給客戶端；所述客戶端將所述第一時間周期內(nèi)各服務的錯誤項目消息進行渲染展示。

優(yōu)選地，所述錯誤項目消息發(fā)送模塊320包括：

錯誤分值計算模塊，適于針對所述錯誤信息進行計算，得到針對所述服務錯誤信息和/或所述服務下的具體事項錯誤信息的錯誤分值，并根據(jù)所述錯 誤分值生成錯誤項目消息；

第一發(fā)送模塊，適于向各第一訂閱者發(fā)送錯誤項目消息；

優(yōu)選地，所述客戶端包括：

第一展示模塊，適于所述客戶端按時間序列將所述錯誤項目消息渲染為圖形化的狀態(tài)圖。

優(yōu)選地，所述客戶端包括：

服務錯誤展示模塊，適于所述客戶端根據(jù)所述錯誤項目消息中對應各服務的服務錯誤信息，優(yōu)先服務錯誤信息進行渲染展示；

具體事項錯誤展示模塊，適于當接收到對一服務錯誤消息的點擊操作，則將所述錯誤項目消息中對應所述服務的具體事項錯誤信息進行渲染展示。

優(yōu)選地，所述錯誤項目消息發(fā)送模塊320包括：

隊列放入模塊，適于根據(jù)所述錯誤信息，生成錯誤項目消息并將所述錯誤項目消息放入zmq隊列；

錯誤項目消息發(fā)送模塊，適于將所述zmq隊列中的錯誤項目消息，發(fā)送給各第一訂閱者loadjs。

優(yōu)選地，所述長連接為websocket連接。

實施例四

參照圖4，其示出了本發(fā)明實施例的一種線上服務的錯誤監(jiān)控裝置的結(jié)構(gòu)示意圖，具體可以包括：

錯誤信息獲取模塊410，適于獲取各個線上服務的實時的錯誤信息；

訂閱記錄模塊420，適于根據(jù)所述錯誤信息，向各第二訂閱者的發(fā)送錯誤項目消息；所述第二訂閱者記錄第一時間周期內(nèi)各服務的錯誤項目消息。

初始信息發(fā)送模塊430，適于判斷客戶端是否是初始與第一訂閱者進行長連接；如果客戶端是初始與第一訂閱者進行長連接，則所述第一訂閱者從所述第二訂閱者處獲取第一時間周期內(nèi)各服務的錯誤項目消息轉(zhuǎn)發(fā)給客戶端；所述客戶端將所述第一時間周期內(nèi)各服務的錯誤項目消息進行渲染展示；如果客戶端不是初始與第一訂閱者進行長連接，則進入錯誤項目消息發(fā)送模塊440。

錯誤項目消息發(fā)送模塊440，適于根據(jù)所述錯誤信息，向各第一訂閱者發(fā)送錯誤項目消息。

轉(zhuǎn)發(fā)模塊450，適于由所述第一訂閱者通過長連接將所述錯誤項目消息轉(zhuǎn)發(fā)給與所述訂閱者對應的客戶端；所述客戶端根據(jù)所述錯誤項目消息進行渲染展示。

實施例五

參照圖5，其示出了本發(fā)明實施例的一種線上服務的錯誤監(jiān)控系統(tǒng)的結(jié)構(gòu)示意圖，具體可以包括：

各個前端服務器510、監(jiān)控服務器520和各個客戶端530；

每個前端服務器510適于運行各種服務，并將各種服務的錯誤信息返回給監(jiān)控服務器；

所述監(jiān)控服務器520包括：

錯誤信息獲取模塊521，適于獲取各個線上服務的實時的錯誤信息；

錯誤項目消息發(fā)送模塊522，適于根據(jù)所述錯誤信息，向各第一訂閱者發(fā)送錯誤項目消息；

轉(zhuǎn)發(fā)模塊523，適于由所述第一訂閱者通過長連接將所述錯誤項目消息轉(zhuǎn)發(fā)給與所述訂閱者對應的客戶端；

每個客戶端530適于，根據(jù)所述錯誤項目消息進行渲染展示。

優(yōu)選的，監(jiān)控服務器520中，在誤信息獲取模塊521之后，還包括：

訂閱記錄模塊，適于根據(jù)所述錯誤信息，向各第二訂閱者的發(fā)送錯誤項目消息；所述第二訂閱者記錄第一時間周期內(nèi)各服務的錯誤項目消息。

其中，前端服務器可以理解為應用服務器。

優(yōu)選的，監(jiān)控服務器520中，在訂閱記錄模塊之后，還包括：

初始信息發(fā)送模塊，適于判斷客戶端是否是初始與第一訂閱者進行長連接；如果客戶端是初始與第一訂閱者進行長連接，則所述第一訂閱者從所述第二訂閱者處獲取第一時間周期內(nèi)各服務的錯誤項目消息轉(zhuǎn)發(fā)給客戶端。

進一步的，所述客戶端適于將所述第一時間周期內(nèi)各服務的錯誤項目消 息進行渲染展示。

優(yōu)選的，監(jiān)控服務器520中，所述錯誤項目消息發(fā)送模塊522包括：

錯誤分值計算模塊，適于針對所述錯誤信息進行計算，得到針對所述服務錯誤信息和/或所述服務下的具體事項錯誤信息的錯誤分值，并根據(jù)所述錯誤分值生成錯誤項目消息；

第一發(fā)送模塊，適于向各第一訂閱者發(fā)送錯誤項目消息。

優(yōu)選地，所述客戶端530包括：

第一展示模塊，適于所述客戶端按時間序列將所述錯誤項目消息渲染為圖形化的狀態(tài)圖。

優(yōu)選地，所述客戶端530包括：

服務錯誤展示模塊，適于所述客戶端根據(jù)所述錯誤項目消息中對應各服務的服務錯誤信息，優(yōu)先服務錯誤信息進行渲染展示；

具體事項錯誤展示模塊，適于當接收到對一服務錯誤消息的點擊操作，則將所述錯誤項目消息中對應所述服務的具體事項錯誤信息進行渲染展示。

優(yōu)選地，監(jiān)控服務器520中，所述錯誤項目消息發(fā)送模塊522包括：

隊列放入模塊，適于根據(jù)所述錯誤信息，生成錯誤項目消息并將所述錯誤項目消息放入zmq隊列；

錯誤項目消息發(fā)送模塊，適于將所述zmq隊列中的錯誤項目消息，發(fā)送給各第一訂閱者loadjs。

優(yōu)選地，所述長連接為websocket連接。

實施例六

參照圖6，其示出了本發(fā)明實施例的一種設備的結(jié)構(gòu)示意圖，所述設備600具體可以包括：

存儲器610，適于存儲可執(zhí)行代碼；

處理器620，適于執(zhí)行所述可執(zhí)行代碼；所述可執(zhí)行代碼執(zhí)行以下步驟的方法；

獲取各個線上服務的實時的錯誤信息；

根據(jù)所述錯誤信息，向各第一訂閱者發(fā)送錯誤項目消息；

由所述第一訂閱者通過長連接將所述錯誤項目消息轉(zhuǎn)發(fā)給與所述訂閱者對應的客戶端；其中，所述客戶端根據(jù)所述錯誤項目消息進行渲染展示。

在本發(fā)明實施例中該種設備可以為監(jiān)控服務器，其中所述可執(zhí)行代碼還可以包括可在監(jiān)控服務器側(cè)執(zhí)行的步驟。

對應于服務器的客戶端中，也可包括存儲器和處理器，存儲器存儲可執(zhí)行代碼，處理器執(zhí)行所述可執(zhí)行代碼，所述可執(zhí)行代碼執(zhí)行以下的步驟的方法：根據(jù)所述錯誤項目消息進行渲染展示。

當然，客戶端側(cè)的可執(zhí)行代碼還可以包括其他可以在客戶端執(zhí)行的步驟。

在此提供的算法和顯示不與任何特定計算機、虛擬系統(tǒng)或者其它設備固有相關(guān)。各種通用系統(tǒng)也可以與基于在此的示教一起使用。根據(jù)上面的描述，構(gòu)造這類系統(tǒng)所要求的結(jié)構(gòu)是顯而易見的。此外，本發(fā)明也不針對任何特定編程語言。應當明白，可以利用各種編程語言實現(xiàn)在此描述的本發(fā)明的內(nèi)容，并且上面對特定語言所做的描述是為了披露本發(fā)明的最佳實施方式。

在此處所提供的說明書中，說明了大量具體細節(jié)。然而，能夠理解，本發(fā)明的實施例可以在沒有這些具體細節(jié)的情況下實踐。在一些實例中，并未詳細示出公知的方法、結(jié)構(gòu)和技術(shù)，以便不模糊對本說明書的理解。

類似地，應當理解，為了精簡本公開并幫助理解各個發(fā)明方面中的一個或多個，在上面對本發(fā)明的示例性實施例的描述中，本發(fā)明的各個特征有時被一起分組到單個實施例、圖、或者對其的描述中。然而，并不應將該公開的方法解釋成反映如下意圖：即所要求保護的本發(fā)明要求比在每個權(quán)利要求中所明確記載的特征更多的特征。更確切地說，如下面的權(quán)利要求書所反映的那樣，發(fā)明方面在于少于前面公開的單個實施例的所有特征。因此，遵循具體實施方式的權(quán)利要求書由此明確地并入該具體實施方式，其中每個權(quán)利要求本身都作為本發(fā)明的單獨實施例。

本領(lǐng)域那些技術(shù)人員可以理解，可以對實施例中的設備中的模塊進行自適應性地改變并且把它們設置在與該實施例不同的一個或多個設備中?？梢?把實施例中的模塊或單元或組件組合成一個模塊或單元或組件，以及此外可以把它們分成多個子模塊或子單元或子組件。除了這樣的特征和/或過程或者單元中的至少一些是相互排斥之外，可以采用任何組合對本說明書(包括伴隨的權(quán)利要求、摘要和附圖)中公開的所有特征以及如此公開的任何方法或者設備的所有過程或單元進行組合。除非另外明確陳述，本說明書(包括伴隨的權(quán)利要求、摘要和附圖)中公開的每個特征可以由提供相同、等同或相似目的的替代特征來代替。

此外，本領(lǐng)域的技術(shù)人員能夠理解，盡管在此所述的一些實施例包括其它實施例中所包括的某些特征而不是其它特征，但是不同實施例的特征的組合意味著處于本發(fā)明的范圍之內(nèi)并且形成不同的實施例。例如，在下面的權(quán)利要求書中，所要求保護的實施例的任意之一都可以以任意的組合方式來使用。

本發(fā)明的各個部件實施例可以以硬件實現(xiàn)，或者以在一個或者多個處理器上運行的軟件模塊實現(xiàn)，或者以它們的組合實現(xiàn)。本領(lǐng)域的技術(shù)人員應當理解，可以在實踐中使用微處理器或者數(shù)字信號處理器(DSP)來實現(xiàn)根據(jù)本發(fā)明實施例的線上服務的錯誤監(jiān)控設備中的一些或者全部部件的一些或者全部功能。本發(fā)明還可以實現(xiàn)為用于執(zhí)行這里所描述的方法的一部分或者全部的設備或者裝置程序(例如，計算機程序和計算機程序產(chǎn)品)。這樣的實現(xiàn)本發(fā)明的程序可以存儲在計算機可讀介質(zhì)上，或者可以具有一個或者多個信號的形式。這樣的信號可以從因特網(wǎng)網(wǎng)站上下載得到，或者在載體信號上提供，或者以任何其他形式提供。

應該注意的是上述實施例對本發(fā)明進行說明而不是對本發(fā)明進行限制，并且本領(lǐng)域技術(shù)人員在不脫離所附權(quán)利要求的范圍的情況下可設計出替換實施例。在權(quán)利要求中，不應將位于括號之間的任何參考符號構(gòu)造成對權(quán)利要求的限制。單詞“包含”不排除存在未列在權(quán)利要求中的元件或步驟。位于元件之前的單詞“一”或“一個”不排除存在多個這樣的元件。本發(fā)明可以借助于包括有若干不同元件的硬件以及借助于適當編程的計算機來實現(xiàn)。在列舉了若干裝置的單元權(quán)利要求中，這些裝置中的若干個可以是通過同一 個硬件項來具體體現(xiàn)。單詞第一、第二、以及第三等的使用不表示任何順序?？蓪⑦@些單詞解釋為名稱。

本發(fā)明公開了A1、一種線上服務的錯誤監(jiān)控方法，包括：

獲取各個線上服務的實時的錯誤信息；

根據(jù)所述錯誤信息，向各第一訂閱者發(fā)送錯誤項目消息；

由所述第一訂閱者通過長連接將所述錯誤項目消息轉(zhuǎn)發(fā)給與所述訂閱者對應的客戶端；其中，所述客戶端根據(jù)所述錯誤項目消息進行渲染展示。

A2、根據(jù)A1所述的方法，在所述獲取各個線上服務的實時的錯誤信息之后，還包括：

根據(jù)所述錯誤信息，向各第二訂閱者的發(fā)送錯誤項目消息；所述第二訂閱者記錄第一時間周期內(nèi)各服務的錯誤項目消息。

A3、根據(jù)A2所述的方法，在根據(jù)所述錯誤信息，向各第二訂閱者的發(fā)送錯誤項目消息；所述第二訂閱者記錄第一時間周期內(nèi)各服務的錯誤項目消息之后，還包括：

判斷客戶端是否是初始與第一訂閱者進行長連接；如果客戶端是初始與第一訂閱者進行長連接，則所述第一訂閱者從所述第二訂閱者處獲取第一時間周期內(nèi)各服務的錯誤項目消息轉(zhuǎn)發(fā)給客戶端；所述客戶端將所述第一時間周期內(nèi)各服務的錯誤項目消息進行渲染展示。

A4、根據(jù)A1所述的方法，所述根據(jù)所述錯誤信息，向各第一訂閱者發(fā)送錯誤項目消息還包括：

針對所述錯誤信息進行計算，得到針對所述服務錯誤信息和/或所述服務下的具體事項錯誤信息的錯誤分值，并根據(jù)所述錯誤分值生成錯誤項目消息；

向各第一訂閱者發(fā)送錯誤項目消息。

A5、根據(jù)A1或A4所述的方法，所述客戶端根據(jù)所述錯誤項目消息進行渲染展示包括：

所述客戶端按時間序列將所述錯誤項目消息渲染為圖形化的狀態(tài)圖。

A6、根據(jù)A1或A4所述的方法，所述客戶端根據(jù)所述錯誤項目消息進 行渲染展示包括：

所述客戶端根據(jù)所述錯誤項目消息中對應各服務的服務錯誤信息，優(yōu)先服務錯誤信息進行渲染展示；

當接收到對一服務錯誤消息的點擊操作，則將所述錯誤項目消息中對應所述服務的具體事項錯誤信息進行渲染展示。

A7、根據(jù)A1所述的方法，所述根據(jù)所述錯誤信息，向各第一訂閱者發(fā)送錯誤項目消息包括：

根據(jù)所述錯誤信息，生成錯誤項目消息并將所述錯誤項目消息放入zmq隊列；

將所述zmq隊列中的錯誤項目消息，發(fā)送給各第一訂閱者loadjs。

A8、根據(jù)A1或A7所述的方法，所述長連接包括websocket連接。

本發(fā)明還公開了B9、一種線上服務的錯誤監(jiān)控裝置，包括：

錯誤信息獲取模塊，適于獲取各個線上服務的實時的錯誤信息；

錯誤項目消息發(fā)送模塊，適于根據(jù)所述錯誤信息，向各第一訂閱者發(fā)送錯誤項目消息；

轉(zhuǎn)發(fā)模塊，適于由所述第一訂閱者通過長連接將所述錯誤項目消息轉(zhuǎn)發(fā)給與所述訂閱者對應的客戶端；所述客戶端根據(jù)所述錯誤項目消息進行渲染展示。

B10、根據(jù)B9所述的裝置，在誤信息獲取模塊之后，還包括：

訂閱記錄模塊，適于根據(jù)所述錯誤信息，向各第二訂閱者的發(fā)送錯誤項目消息；所述第二訂閱者記錄第一時間周期內(nèi)各服務的錯誤項目消息。

B11、根據(jù)B10所述的裝置，在訂閱記錄模塊之后，還包括：

初始信息發(fā)送模塊，適于判斷客戶端是否是初始與第一訂閱者進行長連接；如果客戶端是初始與第一訂閱者進行長連接，則所述第一訂閱者從所述第二訂閱者處獲取第一時間周期內(nèi)各服務的錯誤項目消息轉(zhuǎn)發(fā)給客戶端；所述客戶端將所述第一時間周期內(nèi)各服務的錯誤項目消息進行渲染展示。

B12、根據(jù)B9所述的裝置，所述錯誤項目消息發(fā)送模塊包括：

錯誤分值計算模塊，適于針對所述錯誤信息進行計算，得到針對所述服 務錯誤信息和/或所述服務下的具體事項錯誤信息的錯誤分值，并根據(jù)所述錯誤分值生成錯誤項目消息；

第一發(fā)送模塊，適于向各第一訂閱者發(fā)送錯誤項目消息。

B13、根據(jù)B9或B12所述的裝置，所述客戶端包括：

第一展示模塊，適于所述客戶端按時間序列將所述錯誤項目消息渲染為圖形化的狀態(tài)圖。

B14、根據(jù)B9或B12所述的裝置，所述客戶端包括：

服務錯誤展示模塊，適于所述客戶端根據(jù)所述錯誤項目消息中對應各服務的服務錯誤信息，優(yōu)先服務錯誤信息進行渲染展示；

具體事項錯誤展示模塊，適于當接收到對一服務錯誤消息的點擊操作，則將所述錯誤項目消息中對應所述服務的具體事項錯誤信息進行渲染展示。

B15、根據(jù)B9所述的裝置，所述錯誤項目消息發(fā)送模塊包括：

隊列放入模塊，適于根據(jù)所述錯誤信息，生成錯誤項目消息并將所述錯誤項目消息放入zmq隊列；

錯誤項目消息發(fā)送模塊，適于將所述zmq隊列中的錯誤項目消息，發(fā)送給各第一訂閱者loadjs。

B16、根據(jù)B9或B15所述的裝置，所述長連接為websocket連接。

本發(fā)明還公開了C17、一種線上服務的錯誤監(jiān)控系統(tǒng)，包括：

各個前端服務器、監(jiān)控服務器和各個客戶端；

每個前端服務器適于運行各種服務，并將各種服務的錯誤信息返回給監(jiān)控服務器；

所述監(jiān)控服務器包括：

錯誤信息獲取模塊，適于獲取各個線上服務的實時的錯誤信息；

錯誤項目消息發(fā)送模塊，適于根據(jù)所述錯誤信息，向各第一訂閱者發(fā)送錯誤項目消息；

轉(zhuǎn)發(fā)模塊，適于由所述第一訂閱者通過長連接將所述錯誤項目消息轉(zhuǎn)發(fā)給與所述訂閱者對應的客戶端；

每個客戶端適于，根據(jù)所述錯誤項目消息進行渲染展示。

本發(fā)明還公開了D 18、一種設備，包括：

存儲器，適于存儲可執(zhí)行代碼；

處理器，適于執(zhí)行所述可執(zhí)行代碼；所述可執(zhí)行代碼執(zhí)行以下步驟的方法：

獲取各個線上服務的實時的錯誤信息；

根據(jù)所述錯誤信息，向各第一訂閱者發(fā)送錯誤項目消息；

由所述第一訂閱者通過長連接將所述錯誤項目消息轉(zhuǎn)發(fā)給與所述訂閱者對應的客戶端；其中，所述客戶端根據(jù)所述錯誤項目消息進行渲染展示。