企業IT信息管理人員大多是多重身份，他可能既是管理者又是具體執行者，不可能24小時緊盯監控頁面，實時對所有運行監控參數進行分析。管理軟件如果能提供智能分析，幫信息管理人員及時預警故障隱患，才算是真正起到作用。BTIM系統從以下四個方面做了重點考慮：

事件的發現的范圍是不是夠廣闊，作為重要的事件管理功能拒絕漏網之魚是走出成功的第一步。

是否有能有一個高效而準確的發現機制，對于事件發現來說，高效即時是一個很重要的指標，但是因為要即時的發現實件而產生了大量的誤高或者無用的垃圾事件，這樣的高效即時的發現就沒有意義了。怎么去平衡即時和準確是事件發現機制的一個關鍵點。

事件發生后需要輸出，需要告訴相關的人員。事件輸送的時間、方式、對象等這些事件發生中需要關注的信息點是否能靈活的組合和配置是需要關注的。

事件的后續處理也應該納入事件管理的考慮范圍。對于事件管理來說，如果系統能幫忙判斷一些故障，能自動定位某些故障點，甚至是能自動的解決一些常見的問題，這樣的處理方式就比較完美。最后，事件一定要和流程管理相銜接，和ITIL流程管理兼容，具有ITIL的管理思路。

1  事件廣泛監控

對于事件來說，首先我們要關注的是事件收集的廣泛性。對于業務的事件來說，從上面的分析我們也可以看的出，沒有任何的事件可以說完全的不重要可以忽略不理會的。那既然是這樣，我們就要把所有的和業務系統相關的事件進行收集，納入到系統層面進行分析考慮，這樣也就要求對于事件的收集要達到事無大小，一覽無余的地步。

事件收集的對象包括了從底層的網絡設備、線路、流量、到主機的硬件、端口、基于主機上的操作系統、數據庫、中間件等等。

然后我們需要考慮的事件收集的是手段問題，在這么廣泛的事件收集中我們可以通過以下多種方式來支持事件的收集。

支持Event Log、Syslog。Window主機的Event Log和Unix、Linux主機的Syslog反應了系統的運行狀況，可以及時反應系統運行中的問題，系統支持Event Log和Syslog日志的關鍵字檢索功能，用戶可以定義自己關心的關鍵字，當日志中出現相應的關鍵字時，系統產生告警。

無代理監控技術是真正的無代理，不需要在被管理的主機或者應用上安裝任何的軟件。代理技術采用多種采集方式達到對網絡設備、機房環境、主機、應用和數據庫的監控，這些技術包括：

WMI

PerfMon

HTTP/HTTPS

SQL

Ping

DNS

SNMP

Secure Shell (SSH)

TELNET

JDBC

ODBC等

2  事件發現機制

對于事件發現的機制，目前我們使用的比較多的，也是比較常見的技術有兩種，一種是被動的接受，把所有的事件先接收下來，然后在進行分析。另外一種是主動分析，把需要進行分析的事件先安排好，讓需要分析的事件按照計劃進行采集。下面我們比較細致的來解釋這兩種事件機制的優點和缺點。

2.1、被動事后分析模式

被動事后分析模式是指：所有接收的事件都是系統被動的接受的，主動發出的在設備一方，這種工作模式比較通常的是設備以syslog或者Trip的方式把設備上所有產生的海量事件全部發送給接收端，接受端首先要有一個海量的存儲空間來放下這些事件信息，而且需要若干臺服務器來進行密集的運算來分析這些事件，把這些事件進行分析、壓縮、過濾，關聯等等動作。

這種事件處理的模式典型的優點就是接受的事件全，基本上發生過的事件都沒有遺漏的接收了下來。有利用后期的分析，特別是對一些不可預知事件的分析。但是缺點也是很明顯的對于投資特別大，隨著設備增加，會對網絡的負荷，存儲空間的大小，事件處理服務器的運算能力都有極高的要求。而且這類分析模式由于事件的雜亂性，后期的分析效率比較低，容易造成事件風暴來困擾管理人員。

這類事件處理方式主要用于對于事件需要進行精細分析，而對于投資并不敏感的用戶，例如：電信運營商等。

2.2、主動分析事件模式

主動分析事2.件模式是指：在系統預先建立好事件的發現模式，根據管理人員的要求，主動的去采集一些事件，然后進行分析。這類處理模式發起端通常在事件處理中心以SNMP輪詢的方式通過一個或者多個線程來進行事件采集。把這些數據采集回來以后，然后再由事件中心進行事件分析，關聯，壓縮等等動作。

這類事件處理模式的優點是，事件的產生量小，對于資源的效率量大大的降低。而且由于是預先建立的事件發現模式，對于分析這些事件相對效率提高很多，最明顯的優點是簡單、明確。這類事件處理模式的缺點恰恰是被動事后分析模式的優先，由于是預先定義的事件采集模式，并不是所有的事件都進行采集，這樣就有可能會產生遺漏。

這類事件處理方式主要用于對于事件需要進行廣度分析，對于事件的類型并不是太復雜，基本通過工作中的經驗推斷一些事件的發生的。例如：企業用戶等。

3  靈活的事件輸出

事件發生后，的事件輸出最為重要的是通知相關的人員，這是整個事件輸出的首要任務。在這個前提下事件中心應提供靈活的報警定義，可滿足各種業務需求。管理人員可以根據監控需要，定義故障事件是否觸發報警、發送給哪個角色或人員、以及發送的時間段、發送的內容等等 。用戶還可設置多種報警方式，當事故發生時，不僅以傳統方式習慣的彈出式窗口方式來進行通知用戶，還可通過短信、語音、郵件等多種報警方式，全面及時的通知用戶。這樣就覆蓋到客戶的對于事件輸出的個性話需要，管理人員可以自由的組合某個事件告警可以在不同的時間范圍內，通過不同的輸出方式，給到不同的人員，顯示出不同的事件描述語句。甚至是在管理人員在未確認接受到事件的情況下，事件能定時重復送達，以保證相應的管理人員能收到事件內容。

4  事件的后續處理機制

4.1、提供處理意見

事件通知到管理員后能，按照通常的做法只是提高一個事件的內容就完成了事件告知的任務，但是從管理的角度上來說，都經常說要提供一個知識庫之類的說法，但是這種知識庫都是結合在系統中的，還需要管理人家進行檢索和查詢并進行分析后才能找到相應的解決方案。但是我們換一個思路來想問題，如果在事件的告知的同時系統就能夠提供出相應的事件處理意見將會為管理人員節省大量的時間，能夠更高效率的處理問題。

4.2、主動定位故障位置

當我們了解到業務服務發生故障的時候，首先我們是想是不是能快速的進行故障的定位處理，只有故障進行了準確的定位。接下來才有可能談起故障的排除和恢復。

對于故障的定位，我們最長見的做法可能是直觀的看告警信息，當然這對于一些比較容易判斷比較簡單的故障可以這樣看待。例如：某設備的溫度過高，直接的處理辦法就是調整這個區域的空調的溫度控制值，以達到合理的工作范圍。這樣的判斷是最簡單的，但是不幸的是經過統計這樣簡單的判斷在整個事件處理的比例里面占有不到15％。

更多故障是無法通過告警信息來進行判斷的，是要通過管理人員的經驗和排查才能解決這些看似乎簡單的問題。

4.3、自動啟動應急預案

事件的發生是復雜的，但是又是具有一定的規類的。在實際的運維工作當中發現在一些特定的事件發生后，只要制定相應的結合應急預案就能在第一事件內通過一些自動化的手段來快速的恢復服務的問題。

特點：

支持監控密度可更改的各類信息點監控，包括所有可訪問的SNMP MIB信息點，包括所有BTIM 支持的各類應用、主機、中間件、數據庫參數點

支持針對性附加解決方案，支持定義事件的影響度、緊急度

提供接口規范，支持第三方事件檢測程序的聯入

支持事件的過濾

支持各類檢測手段的組合判斷，預置事件分析方法

通過告警關聯與抑制，提供更廣泛的層次化高級智能事件分析能力

支持多渠道（語音、短信、E_mail、屏幕、第三方程序）的故障告警輸出，不同對象、不同時段通過不同渠道可以得到附加處理意見的不同事件告警信息

支持事件直接驅動預置處理，聯動故障斷網隔離處理

除支持門限式事件檢測外，BTIM 支持基線告警管理