本發(fā)明涉及計算機技術領域，特別是涉及一種故障定位方法及裝置。

背景技術：

隨著信息時代的到來，用戶的需求越來越多樣化，服務運營商為了滿足用戶的需求，開發(fā)了多種服務，這些開發(fā)出的服務之間相互配合，相互調用才能滿足用戶的需求。服務只有依托于服務器才能實現(xiàn)其功能，因此，可以將服務部署在至少一臺服務器上。然而隨著服務的數(shù)量不斷地增加，服務器的數(shù)量也隨之增加，但每一臺服務器中運行的服務均有可能出現(xiàn)故障，而服務器中運行的服務的故障有可能導致響應用戶的任務處理請求失敗，因此，需要對故障進行定位，確定發(fā)生故障的服務所在的服務器，同時確定出現(xiàn)故障的原因，以便于維護人員根據出現(xiàn)故障的原因，及時對該服務器中出現(xiàn)故障的服務進行維修。

在現(xiàn)有技術中，可以通過日志對故障進行定位，具體的方法為：接收目標用戶的故障報修請求；其中，所述故障報修請求包含目標用戶的標識信息；基于該標識信息，在存儲的各個服務器的日志中確認目標日志，其中，目標日志為服務器處理目標用戶的任務處理請求時產生的；對獲取的目標日志進行分析，確定出現(xiàn)故障的服務所在的服務器。通常情況下可以通過上述方式進行故障定位，但由于日志量數(shù)目繁多，逐一進行日志排查速度較慢，因此，難以在短時間內確定目標日志，從而導致故障定位的時間比較長。

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

本發(fā)明實施例的目的在于提供一種故障定位方法及裝置，以實現(xiàn)快速地對故障進行定位。具體技術方案如下：

第一方面，為了達到上述目的，本發(fā)明實施例公開了一種故障定位方法，所述方法包括：

確定目標跟蹤鍵，其中，所述目標跟蹤鍵為用于跟蹤響應目標服務請求的服務器的標識信息；

在本地存儲的日志中確定記錄有所述目標跟蹤鍵的日志，并將所確定的日志確定為目標日志，其中，本地存儲的每一日志均記錄有服務器所響應服務請求對應的跟蹤鍵；

根據所述目標日志中記載的告警信息，定位出現(xiàn)故障的服務所在的服務器。

可選的，所述目標跟蹤鍵由預設數(shù)量個預設類型的數(shù)值組成。

可選的，所述確定目標跟蹤鍵，包括：

接收針對目標服務請求失敗的故障定位請求，其中，所述故障定位請求中攜帶所述目標服務請求的識別信息；

在本地存儲的日志中查詢記錄有所述目標服務請求的識別信息的日志；

根據查詢到的日志中記錄的跟蹤鍵，確定目標跟蹤鍵。

可選的，所述確定目標跟蹤鍵，包括：

檢測本地存儲的日志中是否存在包含預設標識的日志；

如果存在，根據包含所述預設標識的日志中記錄的跟蹤鍵，確定目標跟蹤鍵。

可選的，所述根據所述目標日志中記載的告警信息，確定出現(xiàn)故障的服務所在的服務器，包括：

確定所述目標日志中記載的告警信息對應的告警時間；

將所述目標日志中告警時間最早的日志對應的服務器定位為出現(xiàn)故障的服務所在的服務器。

第二方面，為了達到上述目的，本發(fā)明實施例公開了一種故障定位裝置，所述裝置包括：

第一確定模塊，用于確定目標跟蹤鍵，其中，所述目標跟蹤鍵為用于跟蹤響應目標服務請求的服務器的標識信息；

第二確定模塊，用于在本地存儲的日志中確定記錄有所述目標跟蹤鍵的日志，并將所確定的日志確定為目標日志，其中，本地存儲的每一日志均記錄有服務器所響應服務請求對應的跟蹤鍵；

定位模塊，用于根據所述目標日志中記載的告警信息，定位出現(xiàn)故障的服務所在的服務器。

可選的，所述目標跟蹤鍵由預設數(shù)量個預設類型的數(shù)值組成。

可選的，所述第一確定模塊，包括：

接收子模塊，用于接收針對目標服務請求失敗的故障定位請求，其中，所述故障定位請求中攜帶所述目標服務請求的識別信息；

查詢子模塊，用于在本地存儲的日志中查詢記錄有所述目標服務請求的識別信息的日志；

第一確定子模塊，根據查詢到的日志中記錄的跟蹤鍵，確定目標跟蹤鍵。

可選的，所述第一確定模塊，包括：

檢測子模塊，用于檢測本地存儲的日志中是否存在包含預設標識的日志；

第二確定子模塊，用于在所述檢測子模塊的檢測結果為存在的情況下，根據包含所述預設標識的日志中記錄的跟蹤鍵，確定目標跟蹤鍵。

可選的，所述定位模塊，包括：

第三確定子模塊，用于確定所述目標日志中記載的告警信息對應的告警時間；

定位子模塊，用于將所述目標日志中告警時間最早的日志對應的服務器定位為出現(xiàn)故障的服務所在的服務器。

本發(fā)明實施例提供的故障定位方法及裝置，通過跟蹤鍵快速地確定目標日志，根據目標日志中的告警信息，可以定位出現(xiàn)故障的服務所在的服務器，相較于現(xiàn)有技術，確定目標日志的時間比較短，能夠快速地對故障進行定位。

附圖說明

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

圖1為本發(fā)明實施例提供的一種故障定位方法的流程示意圖；

圖2為本發(fā)明實施例中跟蹤鍵在服務之間傳遞的示意圖；

圖3為本發(fā)明實施例中采用flume收集日志的示意圖；

圖4為本發(fā)明實施例提供的一種故障定位裝置的結構示意圖。

具體實施方式

下面將結合本發(fā)明實施例中的附圖，對本發(fā)明實施例中的技術方案進行清楚、完整地描述，顯然，所描述的實施例僅僅是本發(fā)明一部分實施例，而不是全部的實施例?；诒景l(fā)明中的實施例，本領域普通技術人員在沒有做出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都屬于本發(fā)明保護的范圍。

圖1為本發(fā)明實施例提供的一種故障定位方法的流程示意圖，方法包括：

s101：確定目標跟蹤鍵，其中，所述目標跟蹤鍵為用于跟蹤響應目標服務請求的服務器的標識信息。

具體的，目標跟蹤鍵可以由預設數(shù)量個預設類型的數(shù)值組成。

在本發(fā)明實施例中，跟蹤鍵(traceid)是數(shù)值型時，可以使得跟蹤鍵占用的空間比較固定，生成比較容易，具體的，可以采用隨機算法生成。預設數(shù)量可以為一個或多個，具體可以根據在第一段時間內，服務請求的數(shù)量確定。預設類型可以為整型、長整型等等，示例性的，跟蹤鍵可以由兩個長整型的數(shù)值組成，一個長整型的值空間為2⁶⁴，兩個長整型的值空間為2¹²⁸，則兩個跟蹤鍵相同的概率為1/2¹²⁸，兩個跟蹤鍵相同的概率極小，確保了根據跟蹤鍵確定的日志準確性。

在實際應用中，服務請求由多個服務響應，服務之間相互配合才能完成對服務請求的處理。跟蹤鍵可以是第一個對服務請求進行處理的服務所在的服務器生成的，生成的跟蹤鍵作為服務調用的額外參數(shù)，每次調用都將該跟蹤鍵作為參數(shù)傳遞給新的服務。示例性，跟蹤鍵在服務之間傳遞的示意圖可以如圖2所示，web(worldwideweb，全球廣域網)service(服務)生成跟蹤鍵1，并將該跟蹤鍵1傳遞給http(hypertexttransferprotocol，超文本傳輸協(xié)議)service和rpc(remoteprocedurecallprotocol，遠程過程調用協(xié)議)service，httpservice將跟蹤鍵1傳遞給db(database，數(shù)據庫)service，rpcservice將跟蹤鍵1傳遞給hbaseservice。其中，hbase是一個分布式的、面向列的開源數(shù)據庫。

跟蹤鍵在服務之間傳遞可以理解為一個服務中的服務器響應該服務請求，然后將跟蹤鍵連同其他的參數(shù)傳遞給下一個服務中的服務器。當然，跟蹤鍵也可以是公共組件庫生成的，在公共組件庫中設置跟蹤鍵變量，針對一個服務請求生成一個跟蹤鍵，且隨著服務請求在不同的服務中處理，跟蹤鍵也會隨不同服務的組件中傳遞。跟蹤鍵在公共組件庫中傳遞，與現(xiàn)有技術中的其他參數(shù)在公共組件庫中的傳遞方法相同，在這里不進行贅述。

第一種跟蹤鍵傳遞方法實現(xiàn)比較簡單，但需要額外傳遞跟蹤鍵。第二種跟蹤鍵傳遞方法對用戶透明，且是自動傳遞的，但需要公共組件庫中所有公共組件的支持。需要說明的是，公共組件庫是由公共組件組成的庫，公共組件是可以被外層的組件或程序調用的組件。

在本發(fā)明實施例中，可以通過以下方式確定目標跟蹤鍵：

第一步：接收針對目標服務請求失敗的故障定位請求，其中，所述故障定位請求中攜帶所述目標服務請求的識別信息。

在本發(fā)明實施例中，服務器出現(xiàn)故障會導致服務請求處理失敗，則將會有相應的故障定位請求。該故障定位請求可以是用戶發(fā)送的，也可以是其他系統(tǒng)發(fā)送的，還可以是出現(xiàn)故障的服務所在的服務器發(fā)送的等等，在這里并不進行限定。故障定位請求攜帶了目標服務請求的標識信息，示例性的，該標識信息可以包含發(fā)送目標服務請求的時間、所使用的ip(internetprotocol，網絡之間互連的協(xié)議)地址等等用來確定目標服務請求的信息。

第二步：在本地存儲的日志中查詢記錄有所述目標服務請求的識別信息的日志。

在本發(fā)明實施例中，每個服務所在的每一服務器均可以打印日志，打印日志就是生成日志并將日志保存起來。在一個服務器打印日志的時候，將記錄有該服務器所響應服務請求對應的跟蹤鍵也打印進去。示例性的，服務請求1對應的跟蹤鍵為跟蹤鍵1，則服務器1打印針對服務請求1對應的日志，同時將跟蹤鍵1打印到該日志中。

本發(fā)明實施例提供的故障定位方法可以應用于elasticsearch。elasticsearch是一個基于lucene(全文搜索引擎)的搜索服務器，不僅是一款提供存儲，查詢，檢索的優(yōu)秀的開源搜索引擎，還可以提供即時查詢。在實際應用中，可以將每個服務所部署的服務器上的日志都收集起來存儲在elasticsearch。

在本發(fā)明實施例中，可以利用日志收集工具進行日志的收集，日志收集工具可以為flume、logstash等等。flume是cloudera提供的一個高可用的，高可靠的，分布式的海量日志收集、聚合和傳輸?shù)南到y(tǒng)。示例性的，采用flume收集日志的示意圖可以如圖3所示，可以將flume部署到每一服務中，每個服務中部署的flume進行日志的收集，并將收集的日志存儲到elasticsearch。logstash是一款輕量級的日志收集處理框架，可以方便的把分散的、多樣化的日志收集起來，并進行自定義的處理，然后將收集到的日志傳輸?shù)街付ǖ奈恢谩?/p>

第三步：根據查詢到的日志中記錄的跟蹤鍵，確定目標跟蹤鍵。

在本發(fā)明實施例中，查詢到的日志中不僅包含了目標服務請求的識別信息，還包含了跟蹤鍵，可以將該跟蹤鍵確定為目標跟蹤鍵。

在本發(fā)明實施例中，還可以通過以下方式確定目標跟蹤鍵：

第一步：檢測本地存儲的日志中是否存在包含預設標識的日志。

在實際應用中，elasticsearch存儲所接收的日志，然后，檢測本地存儲的日志中是否存在包含預設標識的日志，這里所說的預設標識可以是告警的標識信息，示例性的，可以是error(錯誤)。如果日志中包含了預設標識，說明該日志對應的服務器中運行的服務可能出現(xiàn)故障，或者是與該服務器處理同一服務請求的其他服務器中運行的服務出現(xiàn)故障。

第二步：根據包含所述預設標識的日志中記錄的跟蹤鍵，確定目標跟蹤鍵。

如果檢測到多個日志中包含有預設標識，且這些日志對針對一個服務請求，則可以直接將包含有預設標識的日志中記錄的跟蹤鍵，確定為目標跟蹤鍵。

如果檢測到多個日志中包含有預設標識，且這些日志對針對不同的服務請求產生的，則可以通過以下兩種方法在檢測到的包含有預設標識的日志中確定目標跟蹤鍵：

第一種：可以將檢測到的包含有預設標識的日志中，包含有同一個跟蹤鍵的日志分為一類。將其中一類日志中的跟蹤鍵確定為目標跟蹤鍵，再根據該目標跟蹤鍵確定目標日志，進而定位出現(xiàn)故障的服務器。然后，在跟蹤鍵沒有被確定為目標跟蹤鍵的其他類日志中，選擇一類日志，將選擇的日志中的跟蹤鍵確定為目標跟蹤鍵。重復執(zhí)行確定目標日志，進而定位出現(xiàn)故障的服務器的步驟，直至每一類包含有預設標識的日志中跟蹤鍵均確定為目標跟蹤鍵。

第二種：可以將檢測到的包含有預設標識的日志中，包含有同一個跟蹤鍵的日志分為一類，分別將每一類日志中的跟蹤鍵確定為目標跟蹤鍵，針對每一類日志中確定的跟蹤鍵，分別執(zhí)行根據目標跟蹤鍵確定目標日志，進而定位出現(xiàn)故障的服務器的步驟。

第一種方法是串行地確定目標跟蹤鍵，第二種方法是并行地確定目標跟蹤鍵，在實際應用中，可以選擇其中的一種方法確定目標跟蹤鍵。

s102：在本地存儲的日志中確定記錄有所述目標跟蹤鍵的日志，并將所確定的日志確定為目標日志，其中，本地存儲的每一日志均記錄有服務器所響應服務請求對應的跟蹤鍵。

需要說明的是，在本地存儲的日志中，確定記錄有目標跟蹤鍵的所有日志。示例性的，日志1、日志2、日志3和日志4都記錄有目標跟蹤鍵，則將日志1、日志2、日志3和日志4確定為目標日志。

本領域內技術人員可以理解的是，任何一臺服務器在運行過程中均可以針對其運行狀態(tài)生成日志，這些日志中可以包括：服務器所處理請求的標識、運行狀態(tài)記錄、處理請求是否成功的標識等等；另外，服務的正常運行是依托于硬件設備的，一個服務的正常運行可能會依托于一臺服務器，也可能依托于多臺服務器；基于上述兩方面情況，可以得知服務請求是由服務所依托的服務器具體響應的，那么這些服務器可以在響應服務請求的過程中生成日志。

具體的，跟蹤鍵與服務請求是相對應的，所以在生成日志的同時可以在日志內容中記錄跟蹤鍵，這樣每一條日志可以清楚、直觀的與各個服務請求相對應。綜合上述情況，能夠實現(xiàn)采用跟蹤鍵對響應該跟蹤鍵對應的服務請求的服務器進行跟蹤，使得可以根據跟蹤鍵，一次性獲取服務器針對該服務請求產生的日志，這樣就根據獲取的日志定位故障，實現(xiàn)一站式定位故障，方便快捷。

s103：根據所述目標日志中記載的告警信息，定位出現(xiàn)故障的服務所在的服務器。

在本發(fā)明實施例中，一個服務器中運行的服務出現(xiàn)故障，則該服務器的日志中會出現(xiàn)告警信息，與該服務器一起響應同一服務請求的服務器的日志中也可能會出現(xiàn)告警信息。示例性的，服務器1、服務器2、服務器3和服務器4依次響應服務請求a，如果服務器3中運行的服務出現(xiàn)故障，則服務器3針對服務請求a產生的日志出現(xiàn)告警信息，服務器1和服務器2針對服務請求a產生的日志也會出現(xiàn)告警信息。對目標日志中的告警信息進行分析，可以定位出現(xiàn)故障的服務所在的服務器。

在本發(fā)明的一個優(yōu)選的實施例中，根據所述目標日志中記載的告警信息，確定出現(xiàn)故障的服務所在的服務器，包括：

確定所述目標日志中記載的告警信息對應的告警時間；

將所述目標日志中告警時間最早的日志對應的服務器定位為出現(xiàn)故障的服務所在的服務器。

這里所說的告警時間為告警信息產生的時間，每一個告警時間對應一個告警信息。一個服務器出現(xiàn)故障，響應的服務請求的日志中記載告警信息，而且響應該服務請求的其他服務器針對該服務請求的日志中也會記載告警信息。因此，可以將目標日志中告警時間最早的日志對應的服務器確定為出現(xiàn)故障的服務器。示例性的，告警時間可以是告警時間戳，確定目標日志中每一日志的告警時間戳，對所確定的告警時間戳按照告警時間戳的先后進行排序，將排在最前面的告警時間戳對應的服務器，定位為出現(xiàn)故障的服務所在的服務器。

在本發(fā)明實施例中，目標日志中不僅記載了告警時間，還記載了出現(xiàn)故障的原因，維護人員可以根據出現(xiàn)故障的原因，確定服務器中的服務具體是哪里出現(xiàn)問題，進而解決該問題，使得該服務器中的服務能夠正常運行，能夠對服務請求進行處理。

應用本發(fā)明實施例，通過跟蹤鍵快速地確定目標日志，根據目標日志中的告警信息，可以定位出現(xiàn)故障的服務所在的服務器，相較于現(xiàn)有技術，確定目標日志的時間比較短，能夠快速地對故障進行定位。

與圖1所示的方法實施例相對應，圖4為本發(fā)明實施例提供的一種故障定位裝置的結構示意圖，裝置包括第一確定模塊201、第二確定模塊202和定位模塊203，其中，

第一確定模塊201，用于確定目標跟蹤鍵，其中，所述目標跟蹤鍵為用于跟蹤響應目標服務請求的服務器的標識信息；

第二確定模塊202，用于在本地存儲的日志中確定記錄有所述目標跟蹤鍵的日志，并將所確定的日志確定為目標日志，其中，本地存儲的每一日志均記錄有服務器所響應服務請求對應的跟蹤鍵；

定位模塊203，用于根據所述目標日志中記載的告警信息，定位出現(xiàn)故障的服務所在的服務器。

具體的，所述目標跟蹤鍵由預設數(shù)量個預設類型的數(shù)值組成。

具體的，所述第一確定模塊201，可以包括接收子模塊、查詢子模塊和第一確定子模塊(圖中未示出)。

接收子模塊，用于接收針對目標服務請求失敗的故障定位請求，其中，所述故障定位請求中攜帶所述目標服務請求的識別信息；

查詢子模塊，用于在本地存儲的日志中查詢記錄有所述目標服務請求的識別信息的日志；

第一確定子模塊，根據查詢到的日志中記錄的跟蹤鍵，確定目標跟蹤鍵。

具體的，所述第一確定模塊201，可以包括檢測子模塊和第二確定子模塊(圖中未示出)。

檢測子模塊，用于檢測本地存儲的日志中是否存在包含預設標識的日志；

第二確定子模塊，用于在所述檢測子模塊的檢測結果為存在的情況下，根據包含所述預設標識的日志中記錄的跟蹤鍵，確定目標跟蹤鍵。

具體的，定位模塊203，可以包括第三確定子模塊和定位子模塊(圖中未示出)。

第三確定子模塊，用于確定所述目標日志中記載的告警信息對應的告警時間；

定位子模塊，用于將所述目標日志中告警時間最早的日志對應的服務器定位為出現(xiàn)故障的服務所在的服務器。

應用本發(fā)明實施例，通過跟蹤鍵快速地確定目標日志，根據目標日志中的告警信息，可以定位出現(xiàn)故障的服務所在的服務器，相較于現(xiàn)有技術，確定目標日志的時間比較短，能夠快速地對故障進行定位。

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

本說明書中的各個實施例均采用相關的方式描述，各個實施例之間相同相似的部分互相參見即可，每個實施例重點說明的都是與其他實施例的不同之處。尤其，對于系統(tǒng)實施例而言，由于其基本相似于方法實施例，所以描述的比較簡單，相關之處參見方法實施例的部分說明即可。

以上所述僅為本發(fā)明的較佳實施例而已，并非用于限定本發(fā)明的保護范圍。凡在本發(fā)明的精神和原則之內所作的任何修改、等同替換、改進等，均包含在本發(fā)明的保護范圍內。