本發(fā)明涉及互聯(lián)網(wǎng)領域，尤其涉及一種異常信息的分析方法及裝置。

背景技術：

服務器的大型分布式軟件系統(tǒng)在使用過程中，往往會發(fā)生不可預料的系統(tǒng)異常和事件，運維和監(jiān)控人員需要得知系統(tǒng)異常，才能做出相應修復動作。目前，服務器監(jiān)測異常信息，一般是先接收到異常信息，然后等到異常信息累計到一定量，再進行分析，導致異常信息分析的實時性較差，并且，在分析異常信息時，一般的人工進行分析，導致異常信息分析的效率和準確性較低。

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

本發(fā)明的主要目的在于提出一種異常信息的分析方法及裝置，旨在解決傳統(tǒng)的異常信息的分析方式，實時性較差的技術問題。

為實現(xiàn)上述目的，本發(fā)明提供的一種異常信息的分析方法，所述異常信息的分析方法包括：

服務器在通過數(shù)據(jù)總線接收終端發(fā)送的異常信息時，抓取所述數(shù)據(jù)總線中的異常信息，其中，異常信息包括異常日志和異常事件；

從規(guī)則庫中提取告警規(guī)則，并緩存到內(nèi)存中；

根據(jù)所述告警規(guī)則對抓取的所述異常信息進行分析；

在分析結(jié)果為告警事件時，將告警事件上報至告警接收源。

優(yōu)選地，所述根據(jù)所述告警規(guī)則對抓取的所述異常信息進行分析的步驟包括：

所述服務器將抓取的所述異常信息推送到分析隊列中；

將所述分析隊列中的異常信息與所述告警規(guī)則進行比對；

在有異常信息的關鍵信息與告警規(guī)則匹配時，確定所述異常信息為告警事件。

優(yōu)選地，所述將所述分析隊列中的異常信息與所述告警規(guī)則進行比對的步驟之前，所述異常信息的分析方法還包括：

所述服務器啟動多個分析器，以便于根據(jù)啟動的各個分析器并行分析所述分析隊列中的異常信息。

優(yōu)選地，所述在分析結(jié)果為告警事件時，將告警事件上報至告警接收源的步驟包括：

在分析結(jié)果為告警事件，且包括多個告警事件時，所述服務器根據(jù)各個告警事件的關鍵信息，生成各個告警事件對應的簽名信息；

將各個告警事件對應的簽名信息依次緩存到簽名信息映射表；

若有告警事件對應的簽名信息與緩存簽名信息一致，則累計所述告警信息的個數(shù)，并上報一個告警事件至告警接收源；

若各個告警事件對應的簽名信息與緩存簽名信息都不一致，則緩存各個告警事件對應的簽名信息，并將各個告警事件上報至告警接收源。

優(yōu)選地，在緩存簽名信息的緩存時長達到預設時長時，刪除所述緩存簽名信息。

此外，為實現(xiàn)上述目的，本發(fā)明還提出一種異常信息的分析裝置，所述異常信息的分析裝置包括：

抓取模塊，用于在通過數(shù)據(jù)總線接收終端發(fā)送的異常信息時，抓取所述數(shù)據(jù)總線中的異常信息，其中，異常信息包括異常日志和異常事件；

提取緩存模塊，用于從規(guī)則庫中提取告警規(guī)則，并緩存到內(nèi)存中；

分析模塊，用于根據(jù)所述告警規(guī)則對抓取的所述異常信息進行分析；

上報模塊，用于在分析結(jié)果為告警事件時，將告警事件上報至告警接收源。

優(yōu)選地，所述分析模塊包括：

推送單元，用于將抓取的所述異常信息推送到分析隊列中；

比對單元，用于將所述分析隊列中的異常信息與所述告警規(guī)則進行比對；

確定單元，用于在有異常信息的關鍵信息與告警規(guī)則匹配時，確定所述異常信息為告警事件。

優(yōu)選地，所述分析模塊還包括：

啟動單元，用于啟動多個分析器，以便于根據(jù)啟動的各個分析器并行分析所述分析隊列中的異常信息。

優(yōu)選地，所述上報模塊包括：

生成單元，用于在分析結(jié)果為告警事件，且包括多個告警事件時，根據(jù)各個告警事件的關鍵信息，生成各個告警事件對應的簽名信息；

緩存單元，用于將各個告警事件對應的簽名信息依次緩存到簽名信息映射表；

累計上報單元，用于若有告警事件對應的簽名信息與緩存簽名信息一致，則累計所述告警信息的個數(shù)，并上報一個告警事件至告警接收源；

緩存上報單元，用于若各個告警事件對應的簽名信息與緩存簽名信息都不一致，則緩存各個告警事件對應的簽名信息，并將各個告警事件上報至告警接收源。

優(yōu)選地，所述異常信息的分析裝置還包括：

刪除模塊，用于在緩存簽名信息的緩存時長達到預設時長時，刪除所述緩存簽名信息。

本發(fā)明提出的異常信息的分析方法及裝置，服務器在通過數(shù)據(jù)總線接收終端發(fā)送的異常信息時，即可抓取所述數(shù)據(jù)總線中的異常信息，然后從規(guī)則庫中提取告警規(guī)則，并緩存到內(nèi)存中，再根據(jù)所述告警規(guī)則對抓取的所述異常信息進行分析，在分析結(jié)果為告警事件時，將告警事件上報至告警接收源，而不用是在異常信息累計到一定量之后，再統(tǒng)一進行分析，本發(fā)明實時抓取異常信息，并由告警規(guī)則對抓取的異常信息進行分析，不僅提高了異常信息分析的實時性，還提高了異常信息分析的效率和準確性。

附圖說明

圖1為本發(fā)明異常信息的分析方法第一實施例的流程示意圖；

圖2為本發(fā)明對抓取的所述異常信息進行分析第一實施例的流程示意圖；

圖3為本發(fā)明對抓取的所述異常信息進行分析第二實施例的流程示意圖；

圖4為本發(fā)明一實施場景示意圖；

圖5為本發(fā)明另一實施場景示意圖；

圖6為本發(fā)明在分析結(jié)果為告警事件時，將告警事件上報至告警接收源較佳實施例的流程示意圖；

圖7為本發(fā)明異常信息的分析裝置第一實施例的功能模塊示意圖；

圖8為圖7中分析模塊的第一細化功能模塊示意圖；

圖9為圖7中分析模塊的第二細化功能模塊示意圖；

圖10為圖7中上報模塊的細化功能模塊示意圖。

本發(fā)明目的的實現(xiàn)、功能特點及優(yōu)點將結(jié)合實施例，參照附圖做進一步說明。

具體實施方式

應當理解，此處所描述的具體實施例僅僅用以解釋本發(fā)明，并不用于限定本發(fā)明。

參照圖1，圖1為本發(fā)明異常信息的分析方法第一實施例的流程示意圖。

在本實施例中，所述異常信息的分析方法包括：

步驟S10，服務器在通過數(shù)據(jù)總線接收終端發(fā)送的異常信息時，抓取所述數(shù)據(jù)總線中的異常信息，其中，異常信息包括異常日志和異常事件；

在本實施例中，所述步驟S10之前，包括終端發(fā)送異常數(shù)據(jù)的步驟，所述終端發(fā)送異常數(shù)據(jù)的方式包括：所述終端先產(chǎn)生兩種類型的異常信息，包括錯誤日志(Error Log)和事件日志(Event Log)，然后通過一個收集器(Error Log Collector)將異常信息收集起來后發(fā)送給服務器。

在本實施例中，服務器先通過中心化的數(shù)據(jù)總線接收終端發(fā)送的異常信息，然后在接收到異常信息時，由實時分析引擎抓取所述數(shù)據(jù)總線中的異常信息。值得注意的是，所述實時分析引擎是一個可水平擴展的分布式集群，具有實時抓取異常信息的功能。所述抓取所述數(shù)據(jù)總線中的異常信息的方式包括：全部抓??；按照預設個數(shù)抓取，即每次抓取預設個數(shù)的異常信息；按照接收時間抓取，即按照先接收到的異常事件先抓取。

步驟S20，從規(guī)則庫中提取告警規(guī)則，并緩存到內(nèi)存中；

步驟S30，根據(jù)所述告警規(guī)則對抓取的所述異常信息進行分析；

在所述數(shù)據(jù)總線中抓取到異常信息時，再從規(guī)則庫中提取告警規(guī)則，并緩存到內(nèi)存中，然后根據(jù)所述告警規(guī)則對抓取所述數(shù)據(jù)總線中的異常信息進行分析。應當理解的是，從規(guī)則庫中提取告警規(guī)則，并緩存到內(nèi)存中，便于后續(xù)確定告警事件的類型。

在本實施例中，為了提高信息分析的準確性，參照圖2，所述步驟S30包括：

步驟S31，所述服務器將抓取的所述異常信息推送到分析隊列中；

在本實施例中，在所述數(shù)據(jù)總線中抓取到異常信息時，先將抓取的所述異常信息推送到分析隊列中，可以理解的是，將異常信息推動到發(fā)送隊列中，使得各個異常信息按照順序依次進行分析，避免了隨機抽取，同時，還避免異常信息抽取的重復抽取。

步驟S32，將所述分析隊列中的異常信息與所述告警規(guī)則進行比對；

步驟S33，在有異常信息的關鍵信息與告警規(guī)則匹配時，確定所述異常信息為告警事件。

接著，將所述分析隊列中的異常信息與所述告警規(guī)則進行比對，具體地：提取異常信息中的關鍵信息，所述關鍵信息包括異常信息的類型、規(guī)則字段以及異常信息的來源，根據(jù)這些關鍵信息，將所述異常信息與告警規(guī)則進行比對，在有異常信息的關鍵信息與告警規(guī)則匹配時，確定所述異常信息為告警事件，并進一步地確定告警事件的類型，具體根據(jù)告警規(guī)則確定，例如，告警事件中的關鍵信息與告警規(guī)則匹配，那么該告警事件就是該告警規(guī)則對應的類型。

進一步地，為了提高異常信息分析的效率，參照圖3，所述步驟S32之前，所述步驟S30還包括：

步驟S34，所述服務器啟動多個分析器，以便于根據(jù)啟動的各個分析器并行分析所述分析隊列中的異常信息。

在本實施例中，將所述分析隊列中的異常信息與所述告警規(guī)則進行比對之前，所述服務器啟先動多個分析器，然后根據(jù)啟動的各個分析器并行分析所述異常信息。

步驟S30，在分析結(jié)果為告警事件時，將告警事件上報至告警接收源。

在本實施例中，在分析結(jié)果為告警事件時，根據(jù)上述已經(jīng)確定的告警事件的類型，將所述告警事件上報至告警接收源中。

具體地，所述步驟S30包括：

將生成的告警事件推送到發(fā)送隊列中；

從發(fā)送隊列中提取告警事件并上報至告警接收源。

為更好理解本實施例，舉例如下，參照圖4：在客戶端(即終端)會產(chǎn)生Error Log(錯誤日志)和Event Log(事件日志)二種類型的異常信息，然后通過一個Error Log Collector(收集器)將異常信息收集起來后發(fā)送給服務器。服務器通過一個Log Data Bus(中心化的日志數(shù)據(jù)總線)來接收所有的異常日志/異常事件，Erroy Log Analyzer(實時分析引擎)實時抓取數(shù)據(jù)總線的異常日志/異常事件，并進行快速分析，如分析出來是一個告警事件，會將告警事件推送到Alert Repository(告警數(shù)據(jù)庫)里，應當理解的是，所有產(chǎn)生的告警信息，以標準數(shù)據(jù)格式存儲在告警數(shù)據(jù)庫中。

實時分析引擎分析異常日志/異常事件的具體方式參照圖5，如圖5所示，Error Log Analyzer(實時分析引擎)的Acceptor組件會從持續(xù)從Log Data Bus中拉取日志數(shù)據(jù)，為提升整體分析的性能，拉取的日志會首先推送到一個日志隊列Log Channel中(即分析隊列)，然后Analysis Manager(分析任務管理器)會負責消費Log Channel(日志通道)里的異常信息，執(zhí)行高性能的異常日志分析工作，也就是說確定異常信息的數(shù)據(jù)量，根據(jù)異常信息的數(shù)據(jù)量確定待啟動的Analysis Worker(分析器)，Analysis Manager再從Rule Repository(規(guī)則庫)中讀取規(guī)則，并且Analysis Manager啟動多個Analysis Worker，讓Analysis Worker抓取不同的異常信息做并行分析。如分析后產(chǎn)生告警，則在構(gòu)建標準的告警事件，送入告警事件隊列Alert Event Channel(即發(fā)送隊列中)中，最終通過一個Alert Reporting Worker，將產(chǎn)生的告警事件上報到監(jiān)控中心或其他告警接收源。

本實施例提出的異常信息的分析方法，服務器在通過數(shù)據(jù)總線接收終端發(fā)送的異常信息時，即可抓取所述數(shù)據(jù)總線中的異常信息，然后從規(guī)則庫中提取告警規(guī)則，并緩存到內(nèi)存中，再根據(jù)所述告警規(guī)則對抓取的所述異常信息進行分析，在分析結(jié)果為告警事件時，將告警事件上報至告警接收源，而不用是在異常信息累計到一定量之后，再統(tǒng)一進行分析，本發(fā)明實時抓取異常信息，并由告警規(guī)則對抓取的異常信息進行分析，不僅提高了異常信息分析的實時性，還提高了異常信息分析的效率和準確性。

可以理解的是，本實施例提供一種在生產(chǎn)環(huán)境對異常日志和異常事件實時分析和告警的能力，監(jiān)聽數(shù)據(jù)總線，分析監(jiān)聽的數(shù)據(jù)，配置告警策略和規(guī)則，及時告警，實現(xiàn)了分析異常日志和異常事件的實時分析，并第一時間產(chǎn)生告警，幫助監(jiān)控人員快速偵測到系統(tǒng)異常。

進一步地，為了提高異常信息分析的智能性，基于第一實施例提出本發(fā)明異常信息的分析方法的第二實施例，在本實施例，參照圖6，所述步驟S40包括：

步驟S41，在分析結(jié)果為告警事件，且包括多個告警事件時，所述服務器根據(jù)各個告警事件的關鍵信息，生成各個告警事件對應的簽名信息；

步驟S42，將各個告警事件對應的簽名信息依次緩存到簽名信息映射表；

步驟S43，若有告警事件對應的簽名信息與緩存簽名信息一致，則累計所述告警信息的個數(shù)，并上報一個告警事件至告警接收源；

步驟S44，若各個告警事件對應的簽名信息與緩存簽名信息都不一致，則緩存各個告警事件對應的簽名信息，并將各個告警事件上報至告警接收源。

在本實施例中，在分析結(jié)果為告警事件，且包括多個告警事件時，所述服務器先根據(jù)各個告警事件的關鍵信息，生成各個告警事件對應的簽名信息。本實施例中，所述簽名信息優(yōu)選為Hash(哈希)簽名信息，然后將各個告警事件對應的簽名信息依次緩存到簽名信息映射表。此時，所述服務器判定告警事件是否已經(jīng)維護在所述簽名信息映射表中，即判定告警事件對應的簽名信息與之前緩存的簽名信息一致，若一致，累計所述告警信息的個數(shù)，即此時確定所述告警事件與之前的告警信息一致，不用上報多次，只要上報其中一個告警事件至告警接收源即可。

若各個告警事件對應的簽名信息與緩存簽名信息都不一致，說明各個告警事件都是唯一類型的，那么將各個告警事件對應的簽名信息緩存到簽名信息映射表中，將各個告警事件都上報至告警接收源。

在本實施例中，相當于是對告警事件執(zhí)行收斂操作，收斂是為了防止服務器中，瞬間接收到大量相同告警，如果沒有收斂機制，告警引擎將面臨瞬間產(chǎn)生大量告警事件的風險，因此，本實施中，可以對同一時刻在多臺主機上同時發(fā)生的異常進行收斂，避免產(chǎn)生大量的重復告警，從而提高了告警信息上報的智能性。

進一步地，為了提高告警事件上報的實時性，在緩存簽名信息的緩存時長達到預設時長時，刪除所述緩存簽名信息。

也就是說，每個告警事件的簽名信息在緩存時，僅僅會緩存一預設時間段，如10秒，在這10秒內(nèi)，若有其它告警事件的簽名信息與緩存簽名信息一致，可認為已經(jīng)上報了告警事件了，無須再上報，若緩存簽名信息的緩存時長超過10秒，則刪除所述緩存簽名信息，后續(xù)再接收到告警信息，即使新接收到的告警信息對應的簽名信息與已經(jīng)刪除的緩存簽名信息一致，也認為當前的告警信息需要上報，重新將新接收到的告警信息對應的簽名信息進行緩存。

本發(fā)明進一步提供一種異常信息的分析裝置。

參照圖7，圖7為本發(fā)明異常信息的分析裝置第一實施例的功能模塊示意圖。

需要強調(diào)的是，對本領域的技術人員來說，圖7所示功能模塊圖僅僅是一個較佳實施例的示例圖，本領域的技術人員圍繞圖7所示的異常信息的分析裝置的功能模塊，可輕易進行新的功能模塊的補充；各功能模塊的名稱是自定義名稱，僅用于輔助理解該異常信息的分析裝置的各個程序功能塊，不用于限定本發(fā)明的技術方案，本發(fā)明技術方案的核心是，各自定義名稱的功能模塊所要達成的功能。

在本實施例中，所述異常信息的分析裝置包括：

抓取模塊10，用于在通過數(shù)據(jù)總線接收終端發(fā)送的異常信息時，抓取所述數(shù)據(jù)總線中的異常信息，其中，異常信息包括異常日志和異常事件；

在本實施例中，抓取模塊10在通過數(shù)據(jù)總線接收終端發(fā)送的異常信息之前，終端先發(fā)送異常數(shù)據(jù)，所述終端發(fā)送異常數(shù)據(jù)的方式包括：所述終端先產(chǎn)生兩種類型的異常信息，包括錯誤日志(Error Log)和事件日志(Event Log)，然后通過一個收集器(Error Log Collector)將異常信息收集起來后發(fā)送給服務器。

在本實施例中，抓取模塊10先通過中心化的數(shù)據(jù)總線接收終端發(fā)送的異常信息，然后在接收到異常信息時，抓取所述數(shù)據(jù)總線中的異常信息。所述抓取模塊10抓取所述數(shù)據(jù)總線中的異常信息的方式包括：全部抓?。话凑疹A設個數(shù)抓取，即每次抓取預設個數(shù)的異常信息；按照接收時間抓取，即按照先接收到的異常事件先抓取。

提取緩存模塊20，用于從規(guī)則庫中提取告警規(guī)則，并緩存到內(nèi)存中；

分析模塊30，用于根據(jù)所述告警規(guī)則對抓取的所述異常信息進行分析；

抓取模塊10在所述數(shù)據(jù)總線中抓取到異常信息時，提取緩存模塊20再從規(guī)則庫中提取告警規(guī)則，并緩存到內(nèi)存中，然后分析模塊30根據(jù)所述告警規(guī)則對抓取所述數(shù)據(jù)總線中的異常信息進行分析。應當理解的是，從規(guī)則庫中提取告警規(guī)則，并緩存到內(nèi)存中，便于后續(xù)確定告警事件的類型。

在本實施例中，為了提高信息分析的準確性，參照圖8，所述分析模塊30包括：

推送單元31，用于將抓取的所述異常信息推送到分析隊列中；

在本實施例中，在所述數(shù)據(jù)總線中抓取到異常信息時，推送單元31先將抓取的所述異常信息推送到分析隊列中，可以理解的是，推送單元31將異常信息推動到發(fā)送隊列中，使得各個異常信息按照順序依次進行分析，避免了隨機抽取，同時，還避免異常信息抽取的重復抽取。

比對單元32，用于將所述分析隊列中的異常信息與所述告警規(guī)則進行比對；

確定單元33，用于在有異常信息的關鍵信息與告警規(guī)則匹配時，確定所述異常信息為告警事件。

接著，比對單元32將所述分析隊列中的異常信息與所述告警規(guī)則進行比對，具體地：提取異常信息中的關鍵信息，所述關鍵信息包括異常信息的類型、規(guī)則字段以及異常信息的來源，根據(jù)這些關鍵信息，比對單元32將所述異常信息與告警規(guī)則進行比對，在有異常信息的關鍵信息與告警規(guī)則匹配時，確定單元33確定所述異常信息為告警事件，并進一步地確定告警事件的類型，具體根據(jù)告警規(guī)則確定，例如，告警事件中的關鍵信息與告警規(guī)則匹配，那么該告警事件就是該告警規(guī)則對應的類型。

進一步地，為了提高異常信息分析的效率，參照圖9，所述分析模塊30還包括：

啟動單元34，用于啟動多個分析器，以便于根據(jù)啟動的各個分析器并行分析所述分析隊列中的異常信息。

在本實施例中，比對單元32將所述分析隊列中的異常信息與所述告警規(guī)則進行比對之前，啟動單元34啟先動多個分析器，然后根據(jù)啟動的各個分析器并行分析所述異常信息。

上報模塊40，用于在分析結(jié)果為告警事件時，將告警事件上報至告警接收源。

在本實施例中，在分析結(jié)果為告警事件時，所述上報模塊40根據(jù)上述已經(jīng)確定的告警事件的類型，將所述告警事件上報至告警接收源中。

具體地，所述上報模塊40用于：

將生成的告警事件推送到發(fā)送隊列中；

從發(fā)送隊列中提取告警事件并上報至告警接收源。

為更好理解本實施例，舉例如下，參照圖4：在客戶端(即終端)會產(chǎn)生Error Log(錯誤日志)和Event Log(事件日志)二種類型的異常信息，然后通過一個Error Log Collector(收集器)將異常信息收集起來后發(fā)送給服務器。服務器通過一個Log Data Bus(中心化的日志數(shù)據(jù)總線)來接收所有的異常日志/異常事件，Erroy Log Analyzer(實時分析引擎)實時抓取數(shù)據(jù)總線的異常日志/異常事件，并進行快速分析，如分析出來是一個告警事件，會將告警事件推送到Alert Repository(告警數(shù)據(jù)庫)里，應當理解的是，所有產(chǎn)生的告警信息，以標準數(shù)據(jù)格式存儲在告警數(shù)據(jù)庫中。

實時分析引擎分析異常日志/異常事件的具體方式參照圖5，如圖5所示，Error Log Analyzer(實時分析引擎)的Acceptor組件會從持續(xù)從Log Data Bus中拉取日志數(shù)據(jù)，為提升整體分析的性能，拉取的日志會首先推送到一個日志隊列Log Channel中(即分析隊列)，然后Analysis Manager(分析任務管理器)會負責消費Log Channel(日志通道)里的異常信息，執(zhí)行高性能的異常日志分析工作，也就是說確定異常信息的數(shù)據(jù)量，根據(jù)異常信息的數(shù)據(jù)量確定待啟動的Analysis Worker(分析器)，Analysis Manager再從Rule Repository(規(guī)則庫)中讀取規(guī)則，并且Analysis Manager啟動多個Analysis Worker，讓Analysis Worker抓取不同的異常信息做并行分析。如分析后產(chǎn)生告警，則在構(gòu)建標準的告警事件，送入告警事件隊列Alert Event Channel(即發(fā)送隊列中)中，最終通過一個Alert Reporting Worker，將產(chǎn)生的告警事件上報到監(jiān)控中心或其他告警接收源。

本實施例提出的異常信息的分析裝置，服務器在通過數(shù)據(jù)總線接收終端發(fā)送的異常信息時，即可抓取所述數(shù)據(jù)總線中的異常信息，然后從規(guī)則庫中提取告警規(guī)則，并緩存到內(nèi)存中，再根據(jù)所述告警規(guī)則對抓取的所述異常信息進行分析，在分析結(jié)果為告警事件時，將告警事件上報至告警接收源，而不用是在異常信息累計到一定量之后，再統(tǒng)一進行分析，本發(fā)明實時抓取異常信息，并由告警規(guī)則對抓取的異常信息進行分析，不僅提高了異常信息分析的實時性，還提高了異常信息分析的效率和準確性。

可以理解的是，本實施例提供一種在生產(chǎn)環(huán)境對異常日志和異常事件實時分析和告警的能力，監(jiān)聽數(shù)據(jù)總線，分析監(jiān)聽的數(shù)據(jù)，配置告警策略和規(guī)則，及時告警，實現(xiàn)了分析異常日志和異常事件的實時分析，并第一時間產(chǎn)生告警，幫助監(jiān)控人員快速偵測到系統(tǒng)異常。

進一步地，為了提高異常信息分析的智能性，基于第一實施例提出本發(fā)明異常信息的分析裝置的第二實施例，在本實施例，參照圖10，所述上報模塊40包括：

生成單元41，用于在分析結(jié)果為告警事件，且包括多個告警事件時，根據(jù)各個告警事件的關鍵信息，生成各個告警事件對應的簽名信息；

緩存單元42，用于將各個告警事件對應的簽名信息依次緩存到簽名信息映射表；

累計上報單元43，用于若有告警事件對應的簽名信息與緩存簽名信息一致，則累計所述告警信息的個數(shù)，并上報一個告警事件至告警接收源；

緩存上報單元44，用于若各個告警事件對應的簽名信息與緩存簽名信息都不一致，則緩存各個告警事件對應的簽名信息，并將各個告警事件上報至告警接收源。

在本實施例中，在分析結(jié)果為告警事件，且包括多個告警事件時，生成單元41先根據(jù)各個告警事件的關鍵信息，生成各個告警事件對應的簽名信息。本實施例中，所述簽名信息優(yōu)選為Hash(哈希)簽名信息，然后緩存單元42將各個告警事件對應的簽名信息依次緩存到簽名信息映射表。此時，判定告警事件是否已經(jīng)維護在所述簽名信息映射表中，即判定告警事件對應的簽名信息與之前緩存的簽名信息一致，若一致，累計上報單元43累計所述告警信息的個數(shù)，即此時確定所述告警事件與之前的告警信息一致，不用上報多次，只要上報其中一個告警事件至告警接收源即可。

若各個告警事件對應的簽名信息與緩存簽名信息都不一致，說明各個告警事件都是唯一類型的，那么緩存上報單元44將各個告警事件對應的簽名信息緩存到簽名信息映射表中，將各個告警事件都上報至告警接收源。

在本實施例中，相當于是對告警事件執(zhí)行收斂操作，收斂是為了防止服務器中，瞬間接收到大量相同告警，如果沒有收斂機制，告警引擎將面臨瞬間產(chǎn)生大量告警事件的風險，因此，本實施中，可以對同一時刻在多臺主機上同時發(fā)生的異常進行收斂，避免產(chǎn)生大量的重復告警，從而提高了告警信息上報的智能性。

進一步地，為了提高告警事件上報的實時性，所述異常信息的分析裝置還包括：

刪除模塊，用于在緩存簽名信息的緩存時長達到預設時長時，刪除所述緩存簽名信息。

也就是說，每個告警事件的簽名信息在緩存時，僅僅會緩存一預設時間段，如10秒，在這10秒內(nèi)，若有其它告警事件的簽名信息與緩存簽名信息一致，可認為已經(jīng)上報了告警事件了，無須再上報，若緩存簽名信息的緩存時長超過10秒，則刪除模塊刪除所述緩存簽名信息，后續(xù)再接收到告警信息，即使新接收到的告警信息對應的簽名信息與已經(jīng)刪除的緩存簽名信息一致，也認為當前的告警信息需要上報，重新將新接收到的告警信息對應的簽名信息進行緩存。

需要說明的是，在本文中，術語“包括”、“包含”或者其任何其它變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、物品或者系統(tǒng)不僅包括那些要素，而且還包括沒有明確列出的其它要素，或者是還包括為這種過程、方法、物品或者系統(tǒng)所固有的要素。在沒有更多限制的情況下，由語句“包括一個……”限定的要素，并不排除在包括該要素的過程、方法、物品或者系統(tǒng)中還存在另外的相同要素。

上述本發(fā)明實施例序號僅僅為了描述，不代表實施例的優(yōu)劣。

以上僅為本發(fā)明的優(yōu)選實施例，并非因此限制本發(fā)明的專利范圍，凡是利用本發(fā)明說明書及附圖內(nèi)容所作的等效結(jié)構(gòu)或等效流程變換，或直接或間接運用在其它相關的技術領域，均同理包括在本發(fā)明的專利保護范圍內(nèi)。