你是一名企業應用IT管理員，在一個陽光明媚的早晨，你興匆匆的來到公司辦公，你所運維的應用系統面向3000名使用者，突然間系統的某一功能不可用了，抑或功能的效能變得非常差，無法滿足使用者的需求，使用者投訴電話連連不斷，上級領導要求儘快恢復並查明原因，你問自己為什麼這異常一點徵兆都沒有，你確定昨天晚上什麼也沒做過，而且你很自信的對應用系統的構成非常熟悉，你嘗試這在腦海裡回顧可能的問題點，你召集了應用系統構成元件的運維管理人員，大家登陸到各自管理裝置上將命令跑了一把，並且每一個人都回復“沒有問題，一切正常”。一輪輪分析診斷下來終於找到了原因，掛載在主機上的某一個儲存卷的訪問響應時間突然變得非常慢。你看看了手錶，大半天的時間就這麼過去了，你再看看會議室中聚集的人群，還在疲憊的分析中。會議上領導狠狠的批評大家，為什麼這麼長時間才定位到問題？為什麼沒有做好應該做的監控？為什麼沒有相關資料趨勢的對比？在為什麼的背後是確實因為異常而造成了實際的業務損失，在一家全國領先的大型金融

監控管理的無形價值運維崗位的價值體現在無形，不能出故障，不能出問題，在整個IT生態圈中要看不到運維的存在，這就是運維管理的最高境界，而“存在即合理”，看似不存在的也會看似不合理，也就看似沒有價值，優秀的運維管理者以及技術人員處在一個極其複雜的矛盾中，但優秀的人員往往對事務的美好是有嚮往與追求的，他們會想盡一切辦法馴服業務層面下的形形色色資源，如同壓制妖魔鬼怪一樣不斷提升運維技能，他們仍舊會螺旋式的追求無形境界。在追求的過程中才能讓他們滿足。

監控商業軟體的選擇商用的運維工具能夠一蹴而就的滿足我們的期望嗎？商業產品能夠在短時間內滿足我們的暫時性的需求，商業監控軟體的購買不僅僅是購入了一套產品，還能夠幫助我們領悟到一套監控管理的方法論，但隨後而來的是什麼？隨著你監控內容、任務越來越明晰，對細節控制要求越來越高，商業軟體此時的弊端也就盡顯無疑。對於那些品牌公司的商業軟體來說，我們還是在不考慮動輒幾百萬價格的產品、服務費用的基礎上考慮問題。當你在招標採購時，所有的銷售人員會告訴你他們的產品支援所有的監控內容，他們的監控系統是最強大的，一旦選型完畢，產品入住，你可能為了增加一個定製化的oracle指令碼監控而被要求需要幾十萬的客戶化費用，這又是另一條規則，IT人員的價值遠遠高於硬體、軟體，當然是優秀IT人員，或者是一名普通的IT人員站在了封閉的軟體系統之上。商用軟體的最大弊端成本昂貴與定製化的不及時。前者可以通過避免品牌產品規避，而後者則更多的依賴於監控產品公司的技術實力，在產品設計時是否考慮到了足夠的靈活性，是否採用公有協議而相容社群外掛，是否由一個強大的售後服務團隊。

當我們需要對某物件進行監控時，我們可以選擇超過上10種的方法，例如對Linuxcpu負載的監控，不同的運維人員可能通過vmstat、top、sar命令來達到目的，為了快速的完成我們的通知工作，我們會在指令碼的末尾加上一句
    echo "`hostname` your cpu loadis too high" | mail [email protected]完成最後的告警通知工作，這是一種非常原始的監控手段，但對於一個基礎的IT運維來說，這樣一行指令碼可能是他以後覆蓋IDC所有監控的起始點，他會逐漸的擴大他的程式碼量，漸漸的開始規劃他自己完整的監控平臺，比如建立標準資料夾結構，包括bin、conf、lib，把所有需要的程式碼、配置檔案、依賴庫全部放進去，之後定義一些鮮為人知的規則，內創的MVC，優雅的面向物件介面實現等等，對於一個初級IT運維人來說這些場景確實是一個比較好的鍛鍊機會，在一天或一個月的時間內完成了自己對監控的理解。這樣的監控實現方式也是程式設計師的“通病”，實現為王，能夠跑起來再說，不關注問題的分析與設計過程。而實際上一套專業的、面向企業級的監控平臺是經過過3~5年的運維經驗後沉澱下來，並由一個團隊來構建的。零散的將排程、採數、通知等動作積聚在一個指令碼中的監控會讓組織的運維工作越來越複雜。再回頭看看監控的手段，我們可以通過哪些方式來獲取監控物件的健康指標資料，監控與被監控物件是不在一個物理容器之內，監控主動方通過TCP/IP協議去抓取所需要的資料，對於網路裝置，常常SNMP協議標準供我們使用，而伺服器作業系統物件，則通常部署一套agent在其上，伺服器上的Java程序，遵循JMX標準來抓取我們所需的內容。行業內除了基礎資源監控外，還強調應用監控，模擬真實使用者發起訪問應用系統，並確認他是否可用，我們會通過httpclient等開源元件封裝一個模擬業務的http請求發起訪問。但應用監控告訴我們的是出問題了，但具體在哪裡出問題還要有底層資源來把持，端到端E2E（end toend）監控指的是覆蓋應用所有組成資源各方面的監控，應用層是一個入口，在這個層面上的監控定製化需求更加強烈。不要期望一個人、一個團隊在半年內建立起一個完善的運維監控平臺。它需要有豐富的監控經驗來幫助我們明確監控需求與工具體系，通過需求來選擇開源或者高性價比的商業化軟體，同時監控工具要保持開放性，要不擁有API介面，要不有易讀的原始碼，運維團隊使用這開放性來提升監控管理效率，做好二次開發。

好的工具讓監控事半功倍，好的原則使告警鉅細靡遺。IDC的基礎資源告警會集中起來，將網路、伺服器、應用等告警資訊在一個終端輸出。組織架構會設定專門的監控職能崗，7*24的對基礎資源進行監控。所謂監控，乃監測與控制，器（工具）在於監測，術（原則）注重控制，再好的利器若未合理運用，就無法發揮其本有的作用。監控崗的原則是什麼？沒高深的道理，也無太多細則，記住四個詞，Watching(監控)、Answer（響應）、Notify（通知）、Track（跟蹤），總結起來就是WANT。
Watching(監控)。原則的最高級別，值班人員保證每隔5分鐘掃一遍監控面板。有人會覺得不夠人性化，我們不是有手機嗎？我們不是有APP推送通知嘛？為什麼非得一直盯著面板呢？對於幾十萬的監控項，常常會出現撲面而來、連連不斷的告警，郵件、訊息類通知方式除非採用分散式專人專屬，否則極易形成垃圾風暴，實際經驗證明郵件、訊息一般作為輔助監控手段。對於集中式監控管理方式，將網路、伺服器、中介軟體等告警集中在一個面板，組織內會定義專門的監控職責，值班人員配備多屏，通過班次輪換，並行監控保證這個原則的執行。

Answer(響應)。對於緊急度高、影響範圍大、級別嚴重的告警要第一時間響應。除了監控面板上顯示的重要告警外，組織內還會定義重大問題處理流程，監控值班人員會從不同的渠道收到告警通知，例如緊急處理流程的郵件列表、上級或相關部門郵件等，值班人員收到郵件後都習慣性的先查問題再反饋，從內部看這種方式對問題處理的過程與結果無太大影響，但外部體驗上會很差。

Notify(通知)。將有效告警通知到處理人，重大問題及時升級。在集中監控下，監控和處理的職能並不在一個人身上，值班人員要對告警進行基本判斷，這條告警是什麼?是在發版本嗎？是已知問題嗎？過濾掉無效告警後通知到它的處理人。處理人的通知分為多種情況，有的通過監控平臺關聯事件系統，直接上報事件給後線工程師處理，有的則通過CMDB查到基礎資源上的應用管理人員，郵件、電話告知處理。監控項與配置項是關聯的，藉助於監控平臺上的“器”，將告警資訊在面板上自動關聯到監控元件的責任人，便於監控值班同事查詢。對於關鍵服務、系統，或者大面積異常的告警，要及時升級，將問題與現象第一時間反饋給上級，待上級決策。

Track(跟蹤)。記錄下待確認、未解決的告警，做好班次交接。值班人員在班次內記錄下所有待確認的告警，比如通知到某技術條線人員檢視某裝置，但對方未確認告警元件已恢復，或告知無需關注的，這類告警要記錄下並轉交給下一班次人員，直到告警恢復，或告警已轉入了問題、事件管理系統中，有專人負責處理，並由流程保證告警問題被解決。

監控平臺的需求分析儘管已有了很多開源的監控平臺工具供我們選擇，如nagios、zabbix，但我們一開始先不進入到一個具體的使用過程，它們都是優秀的開源產品，但我不希望大家一下子就陷入到一個軟體安裝、配置的複雜過程中，我們先搞清楚自己的原始需求是什麼，我們要一個怎樣的監控平臺，在明晰了自己到底要什麼，再來選擇合適的產品，會讓我們後續的工作事半功倍。在附錄中我們會對zabbix的具體使用進行詳細介紹。

排程、規則和告警，一次監控過程在實際的生產環境中我們要對weblogic Java程序進行監控，對linux伺服器進行監控，還要對網路裝置進行監控。那麼我們先來剖析weblogic程序的監控過程。監控程式按照一定的頻率，遵循JMX標準向weblogic程序發起請求，請求的內容是weblogic的各項健康指標，JMX的mbean名稱和屬性則是這個指標，每一個weblogic程序有一批需監控的指標，例如執行緒數、heap大小等等，在將指標資料取回來後，我們先進行資料儲存，以便以後檢視歷史資料，之後按照一定的規則來判斷是否需要發出告警，告警的型別又可以分為郵件、簡訊、監控面板。除了發出告警，你可能還需要對現場資訊進行收集，打一個threaddump是經常使用的方法。我們用一個圖來描述我們這次監控的過程：

上圖對一次簡單的weblogic程序監控過程進行了說明，對於主機我們是否可以有同樣的過程呢？監控程式發起對一個主機的監控訪問，當然，主機會響應我們的請求嗎？對於一般的網路ping、telnet操作會，但對於比較複雜層面的健康指標的請求會響應嗎？比如當前開啟檔案數，當前每個磁碟IO的響應時間等，很可能不會，我們可以設計成ssh自動登陸將指令碼嵌入到命令列傳送給linux主機，我們也可以在主機上開發一個agent程式，接收我們的請求，並按照我們要求返回資料，不管怎樣，我們也可以按照和weblogic的方式一樣請求我們想要的資料，並且取回來後也可以儲存到資料庫中便於日後使用，資料的告警處理以及告警判斷之後的預定義行為設定和weblogic監控是一樣的。在確定主機和weblogic程序一樣可以給予同一個模式進行監控後，我們試著提煉出參與這個過程的物件。

上圖是我們嘗試著從weblogic監控這個需求中提煉出來的類，我們逐一分析。
    Job，我們提到這個類時，最開始想到的是發起一次監控訪問，哦，不對，絕對不是一次。對於一個監控物件而言我們是要持續的對其進行監控，並且遵循一定的時間週期，比如每隔30s訪問一次，既然出現了定時的、週期性的完成一批不同類別的Job，我們需要設計一個排程程式來完成這項任務。對於每一個Job，我們週期性的發起監控請求操作，監控請求的處理時間需要包括在這個週期間隔內，我們的監控間隔是10s，一個監控請求的響應是2s，那麼準確的應該是等待8s後再開啟下次監控情況，而不是在程式請求結束完畢後使用sleep（10）迴圈這個監控請求動作。有兩種意外情況會發生：1排程程式自身繁忙而錯過了對一個任務的啟動，這種情況是可能發生的，因為排程程式要將job分發給一個具體的執行執行緒處理，如果執行執行緒都在忙碌，則排程程式必須等待，一旦錯過原來的排程時間，排程程式應將任務啟動時間調整為當下，下一次任務的啟動時間以當下為基準計算。2監控請求的過程可能會發生異常，監控請求的時間超過了監控週期，對於這種情況，排程程式也需要調整時間，避免重複啟動程式，如下圖所示

除了在錯過正常排程時間後進行自我調整外，排程程式還要考慮到遮蔽時間，在裝置維護、應用版本釋出、定期批處理任務等時段，監控獲取的數值會異常，但這些時間段的異常是允許的，因此排程程式對每一個任務要接收遮蔽時間段引數。在Job的具體細節上，要一次性將所有的Item取回來，例如獲取OS資訊，一次將cpu、記憶體、磁碟資訊全部獲取，而不是發起多次訪問。另外，對於需要認證的步驟，只做一次，之後快取憑證，以便下次使用。Java的JMX訪問如果每次都對遠端使用者進行認證，執行效率會大大降低，因此需要快取subject憑證資訊。在設計排程程式時，對於週期性訪問要區分第一次和以後每一次的邏輯，要留存一個空間儲存Job的全域性性資料。最初所有的Job是存放在資料庫中的，第一次載入後要按照Job的目標訪問地址進行錯開排序，這樣做的原因是避免產生對同一目標地址發起併發訪問，因監控而造成目標物件的效能損耗。根據以上的論述我們需要一個排程程式（Scheduler），它依據一定的時間週期以及遮蔽原則（Timer），對各種各樣的任務（Job）進行排程。
  有大量開源排程庫庫供我們使用，在Java領域我們會使用quartz(http://www.quartz-scheduler.org/)，它可以整合到我們的應用中，按照計劃的時間點以及頻度來執行任務。除了任務的排程與執行外，quartz從企業級架構上考慮設計問題，支援叢集與事務。
    Object，監控物件。我們希望這個監控物件能夠涵蓋所有的監控實體，有服務、主機、網路裝置。實體之間的差別在於如何訪問、採集監控資料，這是一種動作。這些動作又基於不同的協議LDAP、SNMP、HTTP，或者不同的規範框架之下，如JMX。在這裡需要定義一個足夠抽象的介面來掩蓋具體的動作細節，我們定義poller方法來採集監控物件的資料，採集的監控指標定義在了Item中，因此Items會作為引數傳入到collect中。在採集資料時需要建立連線並考慮是否需要保持住這個連線，在這裡有一個連線管理過程。在Job中，對採集回來的資料是執行告警還是動作都是與Object關聯的，Object等同於任務中的門面物件，對採集回來資料進行告警、以及回撥診斷方法都將在這個類中實現。Object的實現類的複雜之處在於poller方法，就以JMX來說，與遠端物件建立起連線的方式就有很多種，筆者遇到過複雜的情況有對weblogic的不同版本通過JMX監控，發起連線的client類名一致，但版本不同，最後在建立連線的動作中實現不同的類載入器才解決此問題。開源產品可以提供一個監控處理的方法與框架，但在細節層面上很難有一個產品的靈活性足夠滿足我們的需求，對於運維來說安裝、配置、啟動一個開源產品非常容易，但要馴服它，完全按照我們的思路運轉則需要花費大量的精力，不管是開源還是商用，只有公開原始碼並且具有對它足夠的控制能力後才能自由的支撐起IT運維，對一個開源產品的二次開發需要專業的開發人員，在這裡也在此強調了運維人員的開發能力。
    Item，監控項，也就是監控物件自身的監控指標，每一個Item有一個獨有名字，比如weblogic執行緒數，我們會將它取名為weblogic.10.jmx.thread.active.count，對這個名稱加上別名，“weblogic10活動執行緒數”，我們還要定義監控項的值型別，是浮點、整型、字元型，對於我們獲取的值我們將如何判斷並處理，因此他必然關聯上rule。Item還要攜帶一類有效資料幫助Object來collect，如果是JMX，他可能是mbean name，而對於SNMP，則是oid編碼。我們要預留足夠的空間給有效資料，它區分為靜態與動態，我們以一個磁碟檢測的Item舉例，Item靜態的是DiskUsageStats，磁碟使用率，它告訴Object物件在收集時獲取什麼型別資料。動態名稱則一個具體的磁碟名稱，例如/nfsc/im_core5，告訴Object具體採集哪個磁碟的，設計Item時考慮到各種問題發生的情況，有時候動態資料還是通過正則表示式實現的，比如/nfsc/im_core*，要檢索所有符合正則表示式的磁碟。
    Rule，規則，對Item的值進行判斷，是否要出發一次告警或動作，並且根據Item的值解析完畢後設置一個狀態，狀態包括OK、INFO、WARN、CRITCAL等等。對於Item來說這是它當前的狀態，對於alert來說這是告警的級別，一個Item關聯到了多個Rule，那麼以最高級別的狀態為準。Rule的屬性中有一個最重要的是規則表示式，“在閥值超過90，並連續三次後，確認為WARN狀態”，這就是一個規則語言，其中包括了邏輯，規則語言的重要性在於將邏輯作為引數傳遞，將邏輯動態化了，rule如同規則引擎般。我們來看看關於weblogic排隊執行緒數的規則表示式，“critical={>,0,2}”，這句話表示當數值大於0且連續兩次則將狀態修改為critical，嚴重。
    我們看看zabbix的的規則表示式，下面是一條cpu負載的表示式:

“www.zabbix.com”表示監控物件，這裡的”system.cpu.load[all,avg1]”類似於Item的唯一屬性，last表示取最近的一次值，當最近的一次值的負載大於5時，則認為有問題。Zabbix的規則比之前的要複雜也完善很多，再來看下面這條規則

當cpu的負載大於5或者在最近10分鐘內負載大於2時確定為異常。讀者注意到，zabbix的設計與上例不一樣了，它的Rule與Item之間是沒有關係的，Rule是以一個集合的方式直接關聯到Object，這樣才可以實現對不同Item之間的與、或的規則定義。Rule到底和誰關聯跟合適，顯而易見Rule應該與Object關聯才能在全量的Item資料中進行匹配判斷，這才是最靈活的，相比於做完一件事後判斷他的對錯，更合適的方式是做完所有的事情後再來全域性判斷，設計細節的會給產品的擴充套件性帶來很大的影響，需求永遠是在變的，為了保持絕對的靈活性，必須深挖需求，這樣才能辨識出物件之間到底是否存在必然的關係。我們在之前的的抽象關聯圖上再進一步細化，並調整關聯關係，如下圖：

    規則表示式中要涵蓋很多元素，閥值，最終Item值對比的數值；操作符，大於、等於或小於；重複次數；zabbix還定義了一些函式對值進行操作，比如取值時間段等等。

Alert，告警。在Rule命中後則會進入到Alert，告警的方式很多，發簡訊、發郵件、dashboard面板展示以及其他方方面面，對於Rule觸發的Alert而言，它僅僅只是把一條訊息傳送到給告警的接收者，但要注意的是在生產環境中非常容易出現告警風暴，筆者經歷過連續不斷的簡訊在凌晨擾人經歷，讓人無法入眠，經驗證明將告警郵件、簡訊廣播到所有的當事人，不如將告警集中在一個dashboard上，由7*24的值班人員負責值班監控。在dashboard面板上，值班人員對告警的響應方式便捷很多，他可以採用註釋、確認、轉事件、升級、問題管理等諸多方法，一個註釋的告警要說明註釋原因以及註釋時間段。為了防止出現風暴、冗餘現象，我們要做一層filter，而這些filter如同Rule一樣也是基於規則的，他們會關聯到Object的維護時間、變更視窗，甚至與實際的應用運維部署動作關聯，從而大量減少無效告警。在Alert傳遞給終端使用者前必須經過層層過濾，在告警型別與告警過濾上來看，開源產品本身無法滿足要求。
    Dashboard告警和MSG(簡訊、郵件)告警方式各有所長。Dashboard是主動型，由監控人主動的從面板中“拉”回告警資訊，在運維職責中，有專門的值班人員負責盯著監控面板，面板定期重新整理，將最新的告警資訊更新進來。MSG是被動型，告警資訊會推送到接收人終端裝置上。 Dashboard的優勢在於在一個集中的面板上展示了所有告警資訊，便於關聯分析；對於重複的告警只顯示一條，可防止告警風暴；對於告警的處理可關聯CMDB，監控人員判斷是否需要聯絡上層業務應用管理員；關聯事件管理系統，對於已知的問題上報case給後端事件團隊。而MSG方式認為，理想情況下告警處理人員可以做自己的事情，只有當告警通知時才開始處理。在大型IDC運維中心，一般將MSG作為一種可選通知方式，而重點採用dashboard方式。智慧手機已經成為日常生活中必不可少的隨身件，將dashboard傳統的網頁版移植到app上，既可以保持原有優勢，同時也可以得到MSG通知功能。
    由於Dashboard是所有告警資訊的集中面板，必須在上游建立告警閥值規則時就確保設定精準，否則會出現大批批無需處理的無效告警，這種規則的調整是一個長期過程，監控項與配置項一樣有專屬的owner團隊，接收前端監控人員的反饋，及時消除無效規則。上述的反饋過程不是馬上見效的，為了保證面板整潔，還需要提供諸多的功能幫助監控人員。告警註釋功能就是其一，註釋告警時定義註釋時長、註釋原因、註釋人；告警轉事件，與ITIL流程管理系統關聯是功能其二，將一條告警轉發給後端團隊處理。
 

  在Dashboard上要保證資訊精簡有效，拒絕無效的資料與格式，類似於在面板中嵌入一個儀表盤的功能是完全無必要，佔用空間大，且只能反映一條當前容量資訊，這類功能屬於“展示”類需求，在監控運維中無實際的用處。

Action，動作。嚴格的說Alert屬於Action的一類，那為什麼要加以區分？Action是一個一個回撥函式，當Rule命中時出發我們採取的行動。我常常苦惱於問題在那麼剎那間而過，雖然保留了一些痕跡、線索，但這些內容是不足以讓我們找到問題根本原因，我們希望有一個自定義的介面讓我們在第一時間執行診斷工具，比如DB主機cpu高，但這個告警出現時，我可以定義一套診斷序列來分析哪個程序cpu高，如果是DB程序，我們看看等待事件、看看topSql等。對於java程序，它打出threaddump、heapdump，對於heapdump的分析還可以延伸至物件之間的引用關係，看到真正是那個物件的佔比高。提供一個開放的介面會引發大家的思考，進而朝運維自動化邁進。

在核心需求的分析完畢後，我們可以對此模組展開設計工作，同步進行的還有其他需求的收集與分析，敏捷迭代開發的過程在於從需求中選擇出最核心的部分進行分析、設計，並開始編碼實現，在隨後的迭代過程組中繼續完善其他非核心需求。

百分位裁剪、趨勢分析、正態分佈，資料圖形化核心需求所關注的是Object的可用性、健康與否以及通知監控人員處理。所有的監控系統同時又需要具備將儲存的Item監控項指標資料圖形化展示的能力。圖形化資料體現在容量、效能兩方面。容量與效能的區別在於我們是否對某一項監控指標有了明確的基線，並且能夠換算成百分比。磁碟的空間使用率、CPU的系統空間使用率就是已度量好基線的容量。而效能則不同，它的基線不是顯而易見的，他代表著在單位容量的情況下完成的業務請求、響應時間、吞吐量，效能調優可以幫助我們在固定的容量資源下完成更多更好的任務，當一切趨於平衡的時候我們要度量出單位容量完成的業務處理能力。圖形展示中的這些容量、效能資料對我們有什麼幫助？我們會在以下的情況中使用這些以時間軸為單位在圖形中展示的資料。
    判斷異常點的依據。我們期望大多數異常的線索在日誌中體現，但很可惜的是異常點本身就不是以一個可記錄的Error出現的。有些異常會在沒有任何日誌記錄的情況下間歇性出現，這個時候我們唯一能夠做的就是從歷史Item資料的突變點中查詢線索。將資料按時間軸，排列在曲線圖、柱狀圖中是我們常用來展示資料的方式。採集了的大量資料在異常判斷時往往只會用到一點點，即便異常本身不出現，某些Item資料在圖中的波動也會引發相關人員的關注並對問題進行查詢。由於採集的資料量比較大，而一般關注的資料的時間都是最近點，在資料點的儲存上會將7天或30天后的資料粒度粗化，以釋放資料儲存空間。每天晚上會有一個後臺批量程式進行資料粒度的有效裁剪。
    百分位數法(percentile)，是資料裁剪的常用演算法。它是統計學術語，如果將一組資料從小到大排序，並計算相應的累計百分位，則某一百分位所對應資料的值就稱為這一百分位的百分位數。可表示為：一組n個觀測值按數值大小排列如，處於p%位置的值稱第p百分位數。
    我們常常說P97，舉例而言，採集回來的cpu使用率資料是以30s為間隔，在100個數據中，我們對其進行排序，保留排在第97位的一個數據，其餘的99個值全部丟棄。實際情況我們不會嚴格的按照P97來計算，而是按照縮放比例，一般會採用1：7的縮放，7個數據排序，取第6位作為有效位，從而壓縮空間。
    對於某些特殊的Item指標的監控資料不高值，比如空閒執行緒數，越低代表越要關注，因此取樣時要使用P3。
    定義基線。我們需要定義Item指標資料的基線，某一個核心業務操作的數量在什麼範圍內是正常的，在什麼情況需要引起我們關注。在業務核心功能訪問量上常常會試著將採集到的資料進行基線建立。比如壽險出單系統，我們採集了過去三個月每週一早上10：00~12：00兩小時內的出單資料，將其分佈在一個X、Y資料軸上，X是我們錄單數，將其作為一個隨即變數，按照正態分佈模型，我們可以計算出當前哪些數值情況是在異常範圍內，需要我們關注。
    正態分佈（Normal Distribution），自然科學與行為科學中的定量現象的一個便捷模型。正態分佈也叫做鐘形分佈，這個名字是因為正態分佈的數值在圖形上類似一口鐘而得來。在一系列的數值當中，靠近中值附近的數值數量最多，而偏離中值的數值數量則不斷減少。人類社會的很多行為都符合正態分佈的特點，那些“大多數”都集中在中值附近，而“非主流”則偏離中值。

   趨勢分析。什麼時候會出現瓶頸，什麼時候要追加資源，對於那些已經給出了預警峰值的容量型資料，可以通過趨勢圖推測出未來到達峰值的時間點。提前做好擴容準備的工作。     

最小二乘法（Least squares）是一種數學優化技術。它在X、Y軸上採集一定數量的點，通過最小化誤差的平方來計算出趨勢直線。對於每一個Item，評估出其預警峰值，在與趨勢直線相交的點為瓶頸點。

圖形展示模組是可配置的，這體現在一張圖中，我們可以將任意Object的Item組合在一張按時間點一致展示。對於多張圖表，我們也可以自定義的將它們組合在一個頁面上，從而形成由使用者完全自定義配置的監控物件集合。
監控項與配置項一樣，要錄入到監控平臺系統中管理，在監控平臺上也要考慮使用者介面基本功能，包括資料錄入、許可權控制，這與配置管理的要求是樣的。Monitor object和CI的屬性很大程度上是重合的，監控項依賴配置項，二者的資料要打通共享。

  有很多開源的WEB前端圖表工具可供使用，按照API要求將資料載入到圖表中。在選擇通用開源工具包前要考慮幾點，包括功能上是否完全滿足自己的需求，開源社群的資料是否充足、瀏覽器的相容性上是否做得處理得好。
   Highcharts（http://www.highcharts.com）是一款純javascript編寫的圖表庫，我們能夠使用它很簡單便捷的在Web網站或Web應用中新增互動性的圖表。在相容性上它做得非常出色，幾乎支援所有的現代瀏覽器，包括IE6 +、iPhone/iPad、Android。它在標準（W3C標準）瀏覽器中使用SVG技術渲染圖形，在遺留的IE瀏覽器中使用VML技術來繪圖。其完全基於本地瀏覽器技術，不依賴任何外掛（例如Flash、java），不需要安裝任何伺服器環境或動態語言庫支援，只需要兩個js檔案就可以執行。目前可繪製直線圖、曲線圖、面積圖、曲線面積圖、面積範圍圖、曲線面積範圍圖、柱狀圖、柱狀範圍圖、條形圖、餅圖、散點圖、箱線圖、氣泡圖、誤差線圖、瀑布圖、雷達圖等，其中很多圖表可以整合在同一個圖形中形成綜合圖，並支援圖表的縮放。    
  Highcharts具備足夠的靈活性，提供豐富的API介面，可以很方便的對圖表的任意點、線和文字等進行增加、刪除和修改操作。支援眾多的Javascript事件，其結合jQuery、MooTools、Prototype等javascript框架提供的Ajax介面，可以實時地從伺服器取得資料並實時重新整理圖表，支援多種資料形式，包括Javascript陣列、json檔案、json物件和表格資料等，這些資料來源可以是本地、不同頁面，甚至是不同網站。
  Highcharts在國內擁有開源的中文站，到目前為止該網站擁有 “中文論壇”、“線上演示”、“中文教程”、“中文API”、“線上測試”、“相關資源”六大核心資源，其中的資源還在不斷完善。 
 
開源借鑑與選擇，zabbix，nagios

日誌分析

監控平臺的部署架構