智能化運維之IT系統(tǒng)統(tǒng)一監(jiān)控預研報告

1、共享知識分享快樂IT 系統(tǒng)統(tǒng)一監(jiān)控預研報告頁眉內(nèi)容共享知識分享快樂目錄IT 系統(tǒng)統(tǒng)一監(jiān)控預研報告 .11引言 .32平臺建設(shè)的目標 .32.1建立健全企業(yè) IT 運行監(jiān)測指標體系 .32.2完善公司業(yè)務(wù)監(jiān)測指標體系，保障業(yè)務(wù)連續(xù)性.42.3管理業(yè)務(wù)系統(tǒng)容量 .53平臺架構(gòu) .531 平臺技術(shù)架構(gòu) .53.1.1采集層 .63.1.2處理層 .63.1.3展現(xiàn)層 .632 平臺功能架構(gòu) .74對新核心系統(tǒng)建設(shè)的要求 .841 規(guī)范系統(tǒng)日志輸出 .843提供服務(wù)持續(xù)可用性監(jiān)控方法 .105結(jié)論11頁眉內(nèi)容共享知識分享快樂1 引言隨著信息系統(tǒng)規(guī)模持續(xù)擴大， 業(yè)務(wù)應(yīng)用的不斷增加， 服務(wù)用戶對象的日益增

2、多， IT 運維管理人員逐漸面臨著三大難題：(1) 設(shè)備和業(yè)務(wù)種類繁多，各類資料信息分散 ，導致位于一線的 IT 運維監(jiān)控人員感知故障的速度晚于信息系統(tǒng)的使用用戶 ，且故障發(fā)生后缺乏對信息系統(tǒng)的整體把控 ；而后臺管理人員也往往因為信息系統(tǒng) 性能數(shù)據(jù) 和故障數(shù)據(jù) 的匱乏而缺少對系統(tǒng)運行健康度的了解。(2) 核心機房可能分布于多個地點 ，部署范圍廣泛，設(shè)備繁雜 ，對于大批最網(wǎng)絡(luò)設(shè)備、主機服務(wù)器、 應(yīng)用系統(tǒng)沒有一個統(tǒng)一的監(jiān)控平臺， 不能制定統(tǒng)一的故障預警管理策略，故障預警效率低，業(yè)務(wù)恢復時間慢 ；(3) 對關(guān)鍵核心業(yè)務(wù)系統(tǒng)的運行健康程度缺乏評估手段和預警措施 ，只能被動等待問題發(fā)生，無法提前采取技術(shù)

3、手段和管理手段規(guī)避問題。在此背景下，總分公司一線運維人員數(shù)量多但是經(jīng)驗不足， 后臺運維工程師經(jīng)驗豐富但是數(shù)量少， 這些矛盾促使我司在新系統(tǒng)建設(shè)時需同步 建設(shè)一套一體化的 IT 運維監(jiān)控和服務(wù)預警平臺 ，協(xié)助以自動化的手段完成信息系統(tǒng)的監(jiān)測和維護。2 平臺建設(shè)的目標2.1建立健全企業(yè) IT 運行監(jiān)測指標體系首先，平臺的主要目標是加大對公司內(nèi)部各遺留及專有監(jiān)控系統(tǒng)的整合力度，提高 IT 運控中心對公司內(nèi)其他分支機構(gòu) IT 系統(tǒng)管理、檢測和把控能力，建立并完善 IT 系統(tǒng)監(jiān)控、 IT 運行事件響應(yīng)、 IT 系統(tǒng)故障處理、 IT 健康度報告、 IT頁眉內(nèi)容共享知識分享快樂運行問題跟蹤和反饋機制，引人自

4、動化 IT 運維管理工具 ，從而在公司內(nèi)部建立健全運行管理控制能力， 實現(xiàn) IT 健康度和業(yè)務(wù)連續(xù)性治理 。在此基礎(chǔ)上， 進一步優(yōu)化監(jiān)控策略， 實現(xiàn)對設(shè)備及服務(wù)項全面、 細粒度的監(jiān)測，預警和管理，主要包含以下方面：（1）打造多平臺環(huán)境下安全穩(wěn)定髙效的檢測代理及檢測工具;（2）在實現(xiàn)對各類業(yè)務(wù)系統(tǒng)、硬件和網(wǎng)絡(luò)設(shè)備、機房環(huán)境等實時檢測的基礎(chǔ)上，完善對新核心系統(tǒng)的全流程監(jiān)控， 根據(jù)性能數(shù)據(jù)進行預警， 并將性能數(shù)據(jù)和故障數(shù)據(jù)引入事件管理平臺進行后續(xù)治理， 以可視化的方式向運維人員提供一覽式的 IT 服務(wù)健康狀況視圖；（3）構(gòu)建集成監(jiān)控平臺，對平臺的檢測插件、檢測機制、預警算法、視圖展現(xiàn)等監(jiān)控資源進行統(tǒng)

5、一管理， 實現(xiàn)大屏集中式告警 ，便于后臺管理人員直觀地看到系統(tǒng)整體健康程度； 通過視圖的靈活組合可以快速定位故障點， 結(jié)合知識庫縮短處理時間。因此， IT 運維自動化是一組將靜態(tài)的設(shè)備結(jié)構(gòu)轉(zhuǎn)化為根據(jù)IT 服務(wù)需求動態(tài)彈性響應(yīng)的策略，目的就是實現(xiàn)IT 運維的質(zhì)量，降低成本。2.2完善公司業(yè)務(wù)監(jiān)測指標體系，保障業(yè)務(wù)連續(xù)性隨著公司信息化的發(fā)展，IT 技術(shù)已經(jīng)從業(yè)務(wù)支持逐步走向與業(yè)務(wù)的融合，并成為公司穩(wěn)健運營和發(fā)展的支柱。公司內(nèi)部很多業(yè)務(wù)流程都已經(jīng)在IT 部門的支持下實現(xiàn)了流程的再造和優(yōu)化， 提煉并制定了相應(yīng)的流程圖、 流程文件及流程運作機制。但是目前我們 對于公司內(nèi)部業(yè)務(wù)風險的管控尚處在初步階段 。

6、各類業(yè)務(wù)流程依然面臨著來自內(nèi)部和外部的各種業(yè)務(wù)風險。 例如內(nèi)部業(yè)務(wù)風險主要來自于員工和服務(wù)商對信息系統(tǒng)的不當應(yīng)用， 如非授權(quán)操作或誤操作； 外部業(yè)務(wù)風險主要來自于外部的不安全事件， 如黑客攻擊、 機房環(huán)境變化等。 對應(yīng)用系統(tǒng)進行頁眉內(nèi)容共享知識分享快樂業(yè)務(wù)監(jiān)控，能夠及時識別業(yè)務(wù)風險， 有效進行相應(yīng)的主動規(guī)避操作，避免造成損失。2.3管理業(yè)務(wù)系統(tǒng)容量通過業(yè)務(wù)監(jiān)控平臺可以密切監(jiān)控業(yè)務(wù)系統(tǒng)性能，包括系統(tǒng)的業(yè)務(wù)處理量、 處理性能、各資源使用狀況等， 通過對系統(tǒng)資源瓶頸的分析，可以降低或提高業(yè)務(wù)系統(tǒng)容量；3 平臺架構(gòu)3 1 平臺技術(shù)架構(gòu)運維平臺能夠?qū)Ω黝愑嬎銠C設(shè)備、網(wǎng)絡(luò)設(shè)備、安全產(chǎn)品、應(yīng)用系統(tǒng)等IT 設(shè)

7、備運行狀況和各種網(wǎng)上行為 進行集中監(jiān)控 ，對各類設(shè)備進行 全面集中的統(tǒng)一管理，及時發(fā)現(xiàn)各類異常情況、快速定位各類事件故障并 自動形成“工單”、自動分派，再由調(diào)度系統(tǒng)進行分派， 由系統(tǒng)按預定流程規(guī)則進行自動化處理或人工處理的運維業(yè)務(wù)信息管理系統(tǒng) 。使運維工作由被動變主動， 由手動處理變成自動處理，并大大降低了運維人員的工作強度，具備良好的延展性 ,如下圖所示 :頁眉內(nèi)容共享知識分享快樂如上圖所示，一體化運維監(jiān)控平臺的系統(tǒng)整體框架由下及上劃分為3 層數(shù)據(jù)采集息（采集層）、數(shù)據(jù)處理層(處理層）和數(shù)據(jù)使用層 (展現(xiàn)層 )。此外，通過平臺的管理控制臺 ,在各個層面都能夠?qū)ζ脚_進行全方位的配置管理。3.1

8、.1采集層采集層主要負責采集信息系統(tǒng)的 性能數(shù)據(jù)和故障數(shù)據(jù) ，通過在信息系統(tǒng)服務(wù)器上部署 Agent, 或者通過 SNMP 協(xié)議采集等多種方式與外圍系統(tǒng)對接， 獲取所述基礎(chǔ)數(shù)據(jù)。采集層被動地接收平臺服務(wù)器發(fā)出的采集指令， 執(zhí)行相關(guān)的信息采集插件，將采集到的數(shù)據(jù)放人隊列和數(shù)據(jù)庫中，便于后續(xù)的分析和數(shù)據(jù)挖掘。3.1.2處理層數(shù)據(jù)處理層根據(jù) 不同監(jiān)控對象的自身特點和運維管理需要 ，靈活定制相應(yīng)的性能指標集 ,定義所述性能指標集中每個指標的監(jiān)測范圍、數(shù)據(jù)來源, 計算方法、預警閾值、測量頻度參數(shù)，通過實時和歷史性能圖表 ，進行監(jiān)測、分析和確定系統(tǒng)性能瓶頸，若超過預警閾值的狀況，自動建立事件，并通知運維人

9、員，由調(diào)度系統(tǒng)進行指派，由運維人員手動處理或按照流程規(guī)則由自動化運維工具處理。3.1.3展現(xiàn)層展現(xiàn)層分 信息系統(tǒng)全局視圖 、系統(tǒng)健康度巡檢報表 、檢測數(shù)據(jù)査詢 三個部分。全局視圖可以展現(xiàn)實時 監(jiān)視告警情況 ，利用巡檢報表， 系統(tǒng)管理員可以分析系統(tǒng)性能狀況，并記錄進事件管理平臺。上述綜合展示通過業(yè)務(wù)視圖、邏輯拓撲、重要設(shè)備、告警統(tǒng)計各個不同視圖，將運維管理工作所關(guān)注的內(nèi)容有序、實時、全面地呈現(xiàn)出信息系統(tǒng)資源和業(yè)務(wù)系統(tǒng)的整體運行狀況。頁眉內(nèi)容共享知識分享快樂32 平臺功能架構(gòu)一體化 IT 運維監(jiān)控模型基于松耦合體系架構(gòu) ,采取靈活模塊化組裝、云計算靈活部署結(jié)構(gòu)，實現(xiàn)“ 監(jiān)控、管理、管控 ”三個方面

10、協(xié)同處理過程 ,其功能架構(gòu)如下：統(tǒng)一訪問門戶通過一次登錄， 即可對所有的平臺功能進行操作， 針對不同的登錄用戶，可以提供專門的個人桌面和輔助工具。監(jiān)測臺可以定義服務(wù)視圖，將性能，流量，報表，拓撲等系統(tǒng)管理所關(guān)心的信息在不同樣式的視圖上集中體現(xiàn)出來。運行服務(wù)平臺以 IT 管理流程為核心，對運維的主要工作進行規(guī)范化的管理 , 并實現(xiàn)設(shè)備維修、值班的管理。頁眉內(nèi)容共享知識分享快樂統(tǒng)一事件管理平臺能夠提供統(tǒng)一的企業(yè)級網(wǎng)絡(luò)事件管理。 通過從各種網(wǎng)絡(luò)設(shè)備和管理平臺收集網(wǎng)絡(luò)事件信息，并進行必要的分析和自動化處理工作。集成數(shù)據(jù)網(wǎng)管系統(tǒng)， 提供數(shù)據(jù)網(wǎng)管標準接口以供信息交互， 完成事件的統(tǒng)一管理，使網(wǎng)絡(luò)和系統(tǒng)中的

11、各種資源得到更加高效的利用和綜合管理。系統(tǒng)管理提供對服務(wù)器、 存儲設(shè)備、操作系統(tǒng)、數(shù)據(jù)庫、中間件、綜合管理，實現(xiàn)系統(tǒng)故障告警管理、系統(tǒng)性能管理、拓撲與配置管理。接收來自防火墻、 人侵檢測、 端口掃描等安全系統(tǒng)的告警， 并將這些告警實時呈現(xiàn)給信息網(wǎng)絡(luò)安全部門， 以采取進一步的響應(yīng)動作， 保障網(wǎng)絡(luò)系統(tǒng)的正常運行，并對網(wǎng)絡(luò)流量進行監(jiān)聽和分析。4 對新核心系統(tǒng)建設(shè)的要求4 1 規(guī)范系統(tǒng)日志輸出目前核心業(yè)務(wù)系統(tǒng)的日志輸出沒有統(tǒng)一的規(guī)范，有些日志采用 log4j進行輸出，有些直接在系統(tǒng)中采用System.out在 nohup.out文件中進行輸出，給運維監(jiān)控分析排查問題帶來較大的困難，建議在新系統(tǒng)的建設(shè)過

12、程中， 統(tǒng)一規(guī)范日志的輸出 :(1) 規(guī)范日志信息級別日志信息輸出的優(yōu)先級從高到低至少應(yīng)分為五檔，分別是Fatal 、ERROR、WARN 、INFO 、DEBUG。這些級別用來指定這條日志信息的重要程度。在測試階段可以打開所有級別的日志，系統(tǒng)上線后只允許輸出INFO 以上級別（含頁眉內(nèi)容共享知識分享快樂INFO ）。各級別的日志信息作用如下：致命（Fatal ） 嚴重的錯誤 ，系統(tǒng)無法正常運行 ，如硬盤空間滿等 。這個級別很少被用 ，常暗含系統(tǒng)或者系統(tǒng)的組件迫近崩潰。錯誤（Error ） 系統(tǒng)可以繼續(xù)運行 ，但最好要盡快修復的錯誤。這個級別用的較多，常常伴隨 Java 異常，錯誤 (Erro

13、r) 的環(huán)境不一定會造成系統(tǒng)的崩潰，系統(tǒng)可以繼續(xù)服務(wù)接下來的請求。警告（ Warn ） 系統(tǒng)可以正常運行 ，但需要引起注意的警告信息。這個級別預示較小的問題 ，由系統(tǒng)外部的因素造成的 ，比如用戶輸入了不符合條件的參數(shù)。信息（ Info ） 系統(tǒng)運行的主要關(guān)鍵時點的操作信息，一般用于記錄業(yè)務(wù)日志。但同時，也應(yīng)該有足夠的信息以保證可以記錄再現(xiàn)缺陷的路徑。這個級別記錄了系統(tǒng)日常運轉(zhuǎn)中有意義的事件。調(diào)試（Debug ） 系統(tǒng)運行中的調(diào)試信息 ，便于開發(fā)人員進行錯誤分析和修正，一般用于程序日志 ，關(guān)心程序操作 (細粒度 )，不太關(guān)心業(yè)務(wù)操作 (粗粒度 )。系統(tǒng)出現(xiàn)問題時 ，必須拋出異常 ，在處理異常時記

14、錄日志 ，且日志級別必須是前三個級別 （FatalErrorWarning）中的一種 。(2) 日志中除包含錯誤信息外，還需包含如下信息：a) Web 應(yīng)用系統(tǒng)發(fā)生異常時， 日志信息中需包含， 系統(tǒng)操作用戶的信息，發(fā)生異常時的業(yè)務(wù)數(shù)據(jù)、系統(tǒng)功能、程序代碼信息及完整的SQL 語句；b) 接口類服務(wù)發(fā)生異常時，日志信息中需包含，接口調(diào)用的 URL，調(diào)用端和被調(diào)用端的實地址，交互報文，報文的檢查結(jié)果，接口響應(yīng)時常；頁眉內(nèi)容共享知識分享快樂c) 在日志中，記錄關(guān)鍵程序和數(shù)據(jù)庫交易的處理時長， 并根據(jù)事先預定的閾值，在日志中以醒目的方式完整的顯示超過閾值的程序代碼的方法名或 SQL 語句，以便運維監(jiān)控人

15、員分析，排查性能隱患。4 2 預留應(yīng)用系統(tǒng)監(jiān)控接口，便于監(jiān)控系統(tǒng)采集相關(guān)指標在核心的建設(shè)過程中， 需預留監(jiān)控接口， 應(yīng)用監(jiān)控系統(tǒng)通過調(diào)用核心系統(tǒng)的監(jiān)控接口，來采集包括但不限于以下指標：a）從 web 頁面對應(yīng)用程序功能進行語義監(jiān)控，比如“頁面加載錯誤”、“Error500 ” 、”Error404 ”；b ）對用戶訪問質(zhì)量的監(jiān)控，頁面加載時常；c）對程序主邏輯進行監(jiān)控，判斷主邏輯是否正常；d ）如果主邏輯正常，則對程序自身占用資源的合理性、程序的性能、和程序的分支功能進行判斷；e） 另外對程序占用的資源情況進行監(jiān)控:CPU 資源的占用，內(nèi)存資源的占用，文件句柄的使用情況，網(wǎng)絡(luò)句柄的使用情況，文

16、件狀態(tài)的進程數(shù)；f） 服務(wù)的監(jiān)控指標，數(shù)據(jù)加載的情況，模塊的處理能力（平均耗時，隊列長度，線程池的使用率），模塊間通訊的狀態(tài)(平均連接時間，讀、寫錯誤數(shù) )，模塊運行時間；g ）系統(tǒng)用戶的操作習慣，完成功能模塊操作的時長；4 3 提供服務(wù)持續(xù)可用性監(jiān)控方法服務(wù)化是應(yīng)用系統(tǒng)發(fā)展的方向，但服務(wù)的監(jiān)控及問題的排查， 一直困擾運維人員，尤其是多層服務(wù)之間調(diào)用問題的排查是相當困難的（例如：服務(wù)調(diào)用頁眉內(nèi)容共享知識分享快樂A->B->C->D，最終結(jié)果依次返回D->C->B->A，中間任何環(huán)節(jié)出現(xiàn)問題， 結(jié)果都返回不到 A ）。建議在新系統(tǒng)的建設(shè)過程中考慮提供服務(wù)的自測工具和監(jiān)控方法，服務(wù)的自測工具以便讓運維人員進行手動的排查問題；監(jiān)控方法，主要是將系統(tǒng)服