一種數據處理方法和裝置與流程

本申請涉及通信技術領域，尤其涉及一種數據處理方法和裝置。

背景技術：

服務器在運行過程中會生成日志，生成的日志存儲在服務器的硬盤上。

當某個或多個服務器在運行過程中發生異常時，只能由用戶查看發生異常的服務器硬盤上的日志數據，通過日志數據的分析來確定問題發生、發生原因等。

然而由于服務器集群的數量非常之大，用戶不可能精確地獲知每一條日志數據分別存儲在哪一臺服務器上，而且在海量的日志數據中更不可能及時查找到關鍵的日志數據。因此當出現問題時，只能由用戶人工手動依次查看每臺服務器硬盤上的日志數據來排查問題，這種方式非常浪費時間成本，效率很低。

技術實現要素：

有鑒于此，本申請提供一種數據處理方法和裝置，以解決現有由用戶人工手動依次查看每臺服務器硬盤上的日志數據來排查問題的方式，非常浪費時間成本，效率很低的問題。技術方案如下：

基于本申請的一方面，本申請提供一種數據處理方法，包括：

根據配置的監控項，連接與所述監控項相關聯的至少一臺服務器；

依據與所述監控項對應的預設規則，從所述至少一臺服務器上獲取與所述監控項對應的至少一組數據；

將獲取到的所述至少一組數據整合后得到一條監控數據；

將所述監控數據存儲至數據庫。

優選地，所述將所述監控數據存儲至數據庫之后，所述方法還包括：

當接收到頁面展示請求時，所述頁面展示請求包括待監控項，從所述數據庫中查找與所述待監控項相關聯的第一監控數據；

將所述第一監控數據以預設展示方式進行展示。

優選地，所述將所述監控數據存儲至數據庫之后，所述方法還包括：

周期性從所述數據庫中獲取第二監控數據；

判斷所述第二監控數據是否滿足報警條件；

如果滿足，執行報警。

優選地，所述執行報警的報警方式包括如下至少一種：發送短信和/或撥打電話至預設終端、控制前端頁面展示報警信息、控制報警燈處于報警狀態，所述報警狀態包括報警燈常亮狀態或報警燈閃爍狀態。

優選地，所述根據配置的監控項，連接與所述監控項相關聯的至少一臺服務器包括：

根據配置的監控項，通過javassh客戶端連接與所述監控項相關聯的至少一臺服務器。

基于本申請的另一方面，本申請還提供一種數據處理裝置，包括：

連接單元，用于根據配置的監控項，連接與所述監控項相關聯的至少一臺服務器；

數據獲取單元，用于依據與所述監控項對應的預設規則，從所述至少一臺服務器上獲取與所述監控項對應的至少一組數據；

數據整合單元，用于將獲取到的所述至少一組數據整合后得到一條監控數據；

存儲單元，用于將所述監控數據存儲至數據庫。

優選地，還包括：

頁面展示請求接收單元，用于接收頁面展示請求，所述頁面展示請求包括待監控項；

監控數據查找單元，用于當所述頁面展示請求接收單元接收到頁面展示請求時，從所述數據庫中查找與所述待監控項相關聯的第一監控數據；

展示單元，用于將所述第一監控數據以預設展示方式進行展示。

優選地，還包括：

監控數據獲取單元，用于周期性從所述數據庫中獲取第二監控數據；

判斷單元，用于判斷所述第二監控數據是否滿足報警條件；

報警單元，用于當所述判斷單元判斷所述第二監控數據滿足報警條件時，執行報警。

優選地，所述報警單元的報警方式包括如下至少一種：發送短信和/或撥打電話至預設終端、控制前端頁面展示報警信息、控制報警燈處于報警狀態，所述報警狀態包括報警燈常亮狀態或報警燈閃爍狀態。

優選地，所述連接單元具體用于，根據配置的監控項，通過javassh客戶端連接與所述監控項相關聯的至少一臺服務器。

本申請根據配置的監控項，連接與所述監控項相關聯的至少一臺服務器，進而依據與所述監控項對應的預設規則，從所述至少一臺服務器上獲取與所述監控項對應的至少一組數據，并將獲取到的所述至少一組數據整合后得到一條監控數據，將所述監控數據存儲至數據庫。本申請將與監控項對應的存儲在不同服務器上的多組數據整合后得到的監控數據存儲至數據庫，當出現問題時，無需用戶人工手動依次查看每臺服務器硬盤上的日志數據，只需依據監控項，即可從數據庫中將與監控項相關聯的監控數據及時快速地查找出來，關鍵的日志數據的抓取更加快速、便捷，問題定位更加及時，大大地縮減了排查問題的時間成本，效率提高。

附圖說明

為了更清楚地說明本申請實施例或現有技術中的技術方案，下面將對實施例或現有技術描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本申請的實施例，對于本領域普通技術人員來講，在不付出創造性勞動的前提下，還可以根據提供的附圖獲得其他的附圖。

圖1為本申請提供的一種數據處理方法的流程圖；

圖2為本申請提供的另一種數據處理方法的流程圖；

圖3為本申請提供的再一種數據處理方法的流程圖；

圖4為本申請提供的一種數據處理裝置的結構示意圖；

圖5為本申請提供的另一種數據處理裝置的結構示意圖；

圖6為本申請提供的再一種數據處理裝置的結構示意圖。

具體實施方式

下面將結合本申請實施例中的附圖，對本申請實施例中的技術方案進行清楚、完整地描述，顯然，所描述的實施例僅僅是本申請一部分實施例，而不是全部的實施例。基于本申請中的實施例，本領域普通技術人員在沒有做出創造性勞動前提下所獲得的所有其他實施例，都屬于本申請保護的范圍。

請參閱圖1，其示出了本申請提供的一種數據處理方法的流程圖，本申請提供的數據處理方法可具體應用于一監控平臺，方法具體包括：

步驟101，根據配置的監控項，連接與所述監控項相關聯的至少一臺服務器。

其中監控項可以是業務中任何一個依賴的第三方服務，也可以是自身業務處理的耗時、請求數量統計、返回結果統計等。本申請的監控平臺包括供用戶操作的前端頁面，用戶可以在前端頁面根據自身不同的服務自行添加監控項。監控平臺根據用戶在前端頁面配置的監控項，自動連接與所述監控項相關聯的至少一臺服務器。本申請支持用戶在前端頁面靈活動態地添加監控項，監控平臺可以兼容不同業務的接入。

在實際應用過程中，每一個業務就是一個服務器集群，服務器集群是指為同一個業務提供服務的服務器組成的集群，一個服務器集群包括至少一臺服務器。如微信業務，該微信業務的底層由多臺服務器為其提供服務，該多臺服務器便組成一個服務器集群。本申請中，用戶在前端頁面配置好監控項后，監控平臺根據該監控項，查找到與所述監控項(即業務)對應的服務器集群，連接該服務器集群中的至少一臺服務器。具體地，監控平臺可以根據配置的監控項，通過javassh(secureshell，專為遠程登錄會話和其他網絡服務提供安全性的協議)客戶端連接與所述監控項相關聯的至少一臺服務器。

步驟102，依據與所述監控項對應的預設規則，從所述至少一臺服務器上獲取與所述監控項對應的至少一組數據。

對于不同的監控項，監控平臺設置有對應不同監控項的不同預設規則，即監控項與預設規則一一對應。例如監控項為接口a的耗時，那么對應接口a的耗時的預設規則可以是，抓取過去5分鐘內調用接口a的總請求數量、平均處理耗時、最大耗時、最小耗時、耗時在0到50毫秒的數量、50到200毫秒的數量、200到500毫秒的數量、500到1000毫秒的數量、1000到2000毫秒的數量、2000到3000毫秒的數量、3000毫秒以上的數量等。又例如監控項為接口a的請求數量，那么對應接口a的請求數量的預設規則可以是，抓取過去5分鐘內調用接口a的總請求數量、最大請求數量、最小請求數量、平均請求數量等。

監控平臺根據用戶配置的監控項，以及預先配置的與監控項對應的預設規則，從與監控項相關聯的至少一臺服務器上獲取與監控項對應的至少一組數據。以前述監控項為接口a的耗時為例來說，監控平臺分別從與接口a相關聯的多臺服務器上依次獲取與接口a相關聯的日志數據，該與接口a相關聯的日志數據為滿足是接口a中且包含耗時數值的日志數據，進而通過對日志數據的分析，獲取到滿足預設規則的一組數據，假設分別為：{1005100116020108200}，即總請求數量為100、平均處理耗時為5、最大耗時為1001、最小耗時為1、耗時在0到50毫秒的數量為60、50到200毫秒的數量為20、200到500毫秒的數量為10、500到1000毫秒的數量為8、1000到2000毫秒的數量為2、2000到3000毫秒的數量為0、3000毫秒以上的數量為0。

因為每一個業務都是一個服務器集群，即一個業務對應多臺服務器，因此監控平臺也會從不同的服務器上獲取到與監控項對應的多組數據。監控平臺在獲取到從一臺服務器上獲取到的多組數據、以及從不同服務器上獲取到的多組數據后，可以將獲取到的所有數據暫時緩存在本地。

步驟103，將獲取到的所述至少一組數據整合后得到一條監控數據。

監控平臺獲取到監控項對應在每個服務器上的多組數據后，將獲取到的所有數據進行整合后得到一條完整的對于該監控項的監控數據。例如監控平臺從一臺服務器中獲取到的接口a的耗時對應的一組數據為{1005100116020108200}，監控平臺一共從10臺服務器中獲取數據，便存在上述形式相同的10組數據，由此監控平臺將該10組數據進行整合。

步驟104，將所述監控數據存儲至數據庫。

監控平臺將整合后得到的監控數據存儲至數據庫。

應用本申請提供的上述技術方案，本申請將與監控項對應的存儲在不同服務器上的多組數據整合后得到的監控數據存儲至數據庫，當出現問題時，無需用戶人工手動依次查看每臺服務器硬盤上的日志數據，只需依據監控項，即可從數據庫中將與監控項相關聯的監控數據及時快速地查找出來，關鍵的日志數據的抓取更加快速、便捷，問題定位更加及時，大大地縮減了排查問題的時間成本，提高了工作效率。

在上述實施例的基礎上，為了便于用戶對監控數據直觀方便地查看，本申請對于監控數據的展示方式作了進一步擴展，具體地，在前述步驟104之后還可以包括，如圖2所示：

步驟105，當監控平臺接收到頁面展示請求時，所述頁面展示請求包括待監控項，從所述數據庫中查找與所述待監控項相關聯的第一監控數據。

步驟106，將所述第一監控數據以預設展示方式進行展示。

其中預設展示方式可以包括餅狀圖、折線圖、柱狀圖、表格等。

例如，用戶在監控平臺的前端頁面發起展示接口b的耗時數據的頁面展示請求，監控平臺接收到用戶發送的展示接口b的耗時數據的頁面展示請求后，從數據庫中查找與接口b的耗時數據相關聯的第一監控數據，具體例如，監控平臺可以從數據庫中將一定時間范圍內(如過去一天)的數據查找出來，進行再次整合，如累加、對比等后，以restful(representationalstatetransfer，一種軟件架構風格)api(applicationprogramminginterface，應用程序編程接口)的風格提供給前端頁面使用，前端頁面將第一監控數據以餅狀圖、折線圖、柱狀圖、或表格等形式進行展示。本申請將監控項的各項指標數據以更直觀形象的展示方式進行展示，助于用戶能夠及時敏感地查看監控數據，使得在系統性能出現下降時，用戶能夠及時發現問題并進行優化，特別是在監控平臺兼容不同業務的動態接入時，監控平臺能夠從業務的角度展示各個監控項的數據，極大地節約了人力開發和排查成本。

在上述實施例的基礎上，本申請還能夠實現問題的自動排查和報警，在步驟104之后，或步驟106之后，還可以包括，如圖3所示：

步驟107，周期性從所述數據庫中獲取第二監控數據。

監控平臺可以利用定時器，周期性從數據庫中獲取第二監控數據。該第二監控數據可以是用戶預先設定好的需要監控的監控項的監控數據，也可以是監控平臺自動默認的監控數據。

步驟108，判斷所述第二監控數據是否滿足報警條件。如果滿足，執行步驟109，如果不滿足，返回步驟107。

用戶可以針對各監控項，在不同的服務器上設置不同的報警閾值，例如監控項為接口c的失敗次數，用戶在服務器a上針對接口c設置的報警閾值為，五分鐘內出現調用接口c的失敗次數為20次。監控平臺獲取數據庫中接口c最近五分鐘的調用情況，當判斷接口c最近五分鐘內調用的失敗次數大于20次，表示接口c的失敗次數滿足報警條件，則觸發報警。

步驟109，執行報警。

本申請中執行報警的報警方式包括如下至少一種：發送短信和/或撥打電話至預設終端，其中預設終端例如為用戶手機、控制前端頁面展示報警信息、控制報警燈處于報警狀態，其中報警狀態包括報警燈常亮狀態或報警燈閃爍狀態等。

本申請通過動態配置監控項以及各監控項對應在不同服務器上的報警閾值，由監控平臺自動實現針對指定業務下的監控項的精確監控和報警，在發生問題時，監控平臺可以第一時間通過報警方式告知用戶，且可以精準地告知用戶發生問題的根源，例如針對指定監控業務下的具體服務的長耗時報警以及某一個錯誤原因的報警，可以幫助用戶及時定位并發現問題，不僅大大減少了排查問題的時間成本，提高了工作效率，且及時準確的報警機制保證了系統的穩定性。

基于前文本申請提供的一種數據處理方法，本申請還提供一種數據處理裝置，該數據處理裝置可具體應用在監控平臺中，如圖4所示，包括：

連接單元100，用于根據配置的監控項，連接與所述監控項相關聯的至少一臺服務器。

其中監控項可以是業務中任何一個依賴的第三方服務，也可以是自身業務處理的耗時、請求數量統計、返回結果統計等。本申請中的監控平臺包括供用戶操作的前端頁面，用戶可以在前端頁面根據自身不同的服務自行添加監控項。連接單元100根據用戶在前端頁面配置的監控項，自動連接與所述監控項相關聯的至少一臺服務器。本申請支持用戶在前端頁面靈活動態地添加監控項，監控平臺可以兼容不同業務的接入。

其中，連接單元100具體用于，根據配置的監控項，通過javassh客戶端連接與所述監控項相關聯的至少一臺服務器。

數據獲取單元200，用于依據與所述監控項對應的預設規則，從所述至少一臺服務器上獲取與所述監控項對應的至少一組數據。

對于不同的監控項，監控平臺設置有對應不同監控項的不同預設規則，即監控項與預設規則一一對應。例如監控項為接口a的耗時，那么對應接口a的耗時的預設規則可以是，抓取過去5分鐘內調用接口a的總請求數量、平均處理耗時、最大耗時、最小耗時、耗時在0到50毫秒的數量、50到200毫秒的數量、200到500毫秒的數量、500到1000毫秒的數量、1000到2000毫秒的數量、2000到3000毫秒的數量、3000毫秒以上的數量等。又例如監控項為接口a的請求數量，那么對應接口a的請求數量的預設規則可以是，抓取過去5分鐘內調用接口a的總請求數量、最大請求數量、最小請求數量、平均請求數量等。

數據獲取單元200根據用戶配置的監控項，以及預先配置的與監控項對應的預設規則，從與監控項相關聯的至少一臺服務器上獲取與監控項對應的至少一組數據。以前述監控項為接口a的耗時為例來說，監控平臺分別從與接口a相關聯的多臺服務器上依次獲取與接口a相關聯的日志數據，該與接口a相關聯的日志數據為滿足是接口a中且包含耗時數值的日志數據，進而通過對日志數據的分析，獲取到滿足預設規則的一組數據，假設分別為：{1005100116020108200}，即總請求數量為100、平均處理耗時為5、最大耗時為1001、最小耗時為1、耗時在0到50毫秒的數量為60、50到200毫秒的數量為20、200到500毫秒的數量為10、500到1000毫秒的數量為8、1000到2000毫秒的數量為2、2000到3000毫秒的數量為0、3000毫秒以上的數量為0。

數據整合單元300，用于將獲取到的所述至少一組數據整合后得到一條監控數據。

數據獲取單元200在獲取到監控項對應在每個服務器上的多組數據后，數據整合單元300將獲取到的所有數據進行整合后得到一條完整的對于該監控項的監控數據。

存儲單元400，用于將所述監控數據存儲至數據庫。

作為本申請的另一個實施例，本申請還包括，如圖5所示：

頁面展示請求接收單元500，用于接收頁面展示請求，所述頁面展示請求包括待監控項；

監控數據查找單元600，用于當所述頁面展示請求接收單元500接收到頁面展示請求時，從所述數據庫中查找與所述待監控項相關聯的第一監控數據；

展示單元700，用于將所述第一監控數據以預設展示方式進行展示。

其中預設展示方式可以包括餅狀圖、折線圖、柱狀圖、表格等。

作為本申請的再一個實施例，本申請還包括，如圖6所示：

監控數據獲取單元800，用于周期性從所述數據庫中獲取第二監控數據；

判斷單元900，用于判斷所述第二監控數據是否滿足報警條件；

報警單元1000，用于當所述判斷單元900判斷所述第二監控數據滿足報警條件時，執行報警。

其中，所述報警單元1000的報警方式包括如下至少一種：發送短信和/或撥打電話至預設終端、控制前端頁面展示報警信息、控制報警燈處于報警狀態，所述報警狀態包括報警燈常亮狀態或報警燈閃爍狀態。

需要說明的是，本說明書中的各個實施例均采用遞進的方式描述，每個實施例重點說明的都是與其他實施例的不同之處，各個實施例之間相同相似的部分互相參見即可。對于裝置類實施例而言，由于其與方法實施例基本相似，所以描述的比較簡單，相關之處參見方法實施例的部分說明即可。

最后，還需要說明的是，在本文中，諸如第一和第二等之類的關系術語僅僅用來將一個實體或者操作與另一個實體或操作區分開來，而不一定要求或者暗示這些實體或操作之間存在任何這種實際的關系或者順序。而且，術語“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、物品或者設備不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、物品或者設備所固有的要素。在沒有更多限制的情況下，由語句“包括一個……”限定的要素，并不排除在包括所述要素的過程、方法、物品或者設備中還存在另外的相同要素。

以上對本申請所提供的一種數據處理方法和裝置進行了詳細介紹，本文中應用了具體個例對本申請的原理及實施方式進行了闡述，以上實施例的說明只是用于幫助理解本申請的方法及其核心思想；同時，對于本領域的一般技術人員，依據本申請的思想，在具體實施方式及應用范圍上均會有改變之處，綜上所述，本說明書內容不應理解為對本申請的限制。