工欲善其事，必先利其器。上篇我們已經(jīng)詳細(xì)分享了監(jiān)控相關(guān)的知識(shí)，然而運(yùn)維可視化，除了構(gòu)造可視化監(jiān)控外，還要建立相應(yīng)的運(yùn)維手段，云化下的運(yùn)維工具和傳統(tǒng)架構(gòu)的有較大不同，對(duì)集群式、分布式提出了更高的要求。

　　作者介紹

　　朱祥磊，山東移動(dòng)BOSS系統(tǒng)架構(gòu)師，負(fù)責(zé)業(yè)務(wù)支撐系統(tǒng)架構(gòu)規(guī)劃和建設(shè)。獲國(guó)家級(jí)創(chuàng)新獎(jiǎng)1項(xiàng)、通信行業(yè)級(jí)科技進(jìn)步獎(jiǎng)2項(xiàng)、移動(dòng)集團(tuán)級(jí)業(yè)務(wù)服務(wù)創(chuàng)新獎(jiǎng)3項(xiàng)。

　　工具篇：構(gòu)建可視化分布式運(yùn)維手段

　　工欲善其事，必先利其器。上篇我們已經(jīng)詳細(xì)分享了監(jiān)控相關(guān)的知識(shí)，然而運(yùn)維可視化，除了構(gòu)造可視化監(jiān)控外，還要建立相應(yīng)的運(yùn)維手段，云化下的運(yùn)維工具和傳統(tǒng)架構(gòu)的有較大不同，對(duì)集群式、分布式提出了更高的要求。

　　1、自動(dòng)化巡檢

　　從2011年開始推行巡檢，最初，我們的武器僅僅是一個(gè)word文檔、一些excel表格和大量的SHELL腳本，檢查靠人工敲擊命令或者查看表數(shù)據(jù)，內(nèi)容也多數(shù)都僅限于日常維護(hù)中已經(jīng)存在的主機(jī)，數(shù)據(jù)庫(kù)，中間件，進(jìn)程狀態(tài)等，執(zhí)行效率較差，并且未真正涉及業(yè)務(wù)類的健康檢查。

　　從2014年12月開始，正式引入自動(dòng)化巡檢工具，工具對(duì)原來積累的腳本進(jìn)行整合，提供可視化操作局面，能夠定期自動(dòng)執(zhí)行、自動(dòng)生成巡檢分析報(bào)告，巡檢內(nèi)容涵蓋主機(jī)、數(shù)據(jù)庫(kù)、中間件、應(yīng)用在內(nèi)的所有監(jiān)控對(duì)象，并且隨著巡檢的深入，在2015年起又增加了業(yè)務(wù)級(jí)別的巡檢內(nèi)容，對(duì)于一些關(guān)鍵業(yè)務(wù)關(guān)鍵點(diǎn)也定期進(jìn)行巡視分析。

　　1)自動(dòng)化巡檢內(nèi)容

　　目前自動(dòng)化巡檢對(duì)象涵蓋了所有的生產(chǎn)主機(jī)，固定巡檢內(nèi)容主要包括常見的系統(tǒng)安全隱患、入侵攻擊檢查，安全補(bǔ)丁檢查，系統(tǒng)配置、加固檢查，數(shù)據(jù)庫(kù)安全配置檢查，詳細(xì)如下：

　　巡檢工具把歷史積累的SHELL腳本參考上面內(nèi)容進(jìn)行逐步歸類，作為巡檢工具的基礎(chǔ)項(xiàng)，也可以隨時(shí)對(duì)巡檢內(nèi)容進(jìn)行修改，所有的巡檢動(dòng)作全部可視化，并且巡視項(xiàng)、巡檢方式、巡檢主機(jī)等全部可以進(jìn)行定制，巡檢任務(wù)結(jié)束后會(huì)自動(dòng)生成巡檢報(bào)告，并能通過郵件、短信等渠道第一時(shí)間告知關(guān)注人。

　　2)自動(dòng)化巡檢效果

　　從2014年底以來，通過將日常巡檢報(bào)告自動(dòng)化，不斷來提升運(yùn)維的自動(dòng)化程度，通過腳本管理、故障診斷、拓?fù)鋱D執(zhí)行遠(yuǎn)程命令調(diào)用等功能規(guī)范日常運(yùn)維操作。通過巡檢可以保存系統(tǒng)性能數(shù)據(jù)、容量信息、配置信息為系統(tǒng)維護(hù)、升級(jí)、擴(kuò)容提供決策數(shù)據(jù)支持;同事通過靈活的工具定制，達(dá)到了對(duì)各種等資源全面的監(jiān)控、多級(jí)鉆取實(shí)現(xiàn)性能分析，提升運(yùn)維的專業(yè)化水平。

　　2015年中開始，在實(shí)現(xiàn)系統(tǒng)自動(dòng)化巡檢后，我們?cè)俳釉賲�，終于實(shí)現(xiàn)了業(yè)務(wù)巡檢的工具化，目前業(yè)務(wù)相關(guān)的巡檢包已涵蓋了系統(tǒng)安全、無紙化、服開配置、業(yè)務(wù)規(guī)則等巡檢內(nèi)容共計(jì)10類28項(xiàng)業(yè)務(wù)，能夠隨時(shí)掌控關(guān)鍵業(yè)務(wù)監(jiān)控度，具體的業(yè)務(wù)巡檢內(nèi)容和界面如下：

　　2、自動(dòng)化JOB

　　在系統(tǒng)日常運(yùn)維中，存在大量重復(fù)并且簡(jiǎn)單的運(yùn)維操作，包括最常見主機(jī)、中間件、數(shù)據(jù)庫(kù)等不同類型的軟、硬件平臺(tái)運(yùn)維。這些運(yùn)維操作重復(fù)而機(jī)械，卻易于出錯(cuò)，占用了大量日常運(yùn)維人員的精力和時(shí)間。

　　通過運(yùn)維自動(dòng)化工具，將運(yùn)維操作場(chǎng)景化、可視化、自動(dòng)化和標(biāo)準(zhǔn)化，將以前需要編輯大量腳本和命令進(jìn)行的維護(hù)操作變?yōu)橹恍枰�點(diǎn)擊相關(guān)的場(chǎng)景調(diào)用以及輸入合適的參數(shù)，大幅減少運(yùn)維人員在編寫腳本和命令分發(fā)執(zhí)行所帶來的資源投入。

　　日常運(yùn)維場(chǎng)景

　　日常運(yùn)維場(chǎng)景是將系統(tǒng)管理員的日常工作項(xiàng)目，集成于同一界面，可對(duì)自動(dòng)執(zhí)行的任務(wù)進(jìn)行處理，并提供統(tǒng)一接入入口和監(jiān)控界面。

　　首先，系統(tǒng)管理員先進(jìn)行任務(wù)配置，系統(tǒng)管理在任務(wù)配置頁(yè)面，進(jìn)行任務(wù)分類與任務(wù)的配置。使用日常任務(wù)之前，需要先配置在相應(yīng)的任務(wù)分類下配置任務(wù)，才能使用。

　　此后，系統(tǒng)管理員在任務(wù)視圖是各分類的任務(wù)的執(zhí)行頁(yè)面。配置任務(wù)完成后，打開任務(wù)視圖，可看到不同任務(wù)分類下已配置的任務(wù)，點(diǎn)擊執(zhí)行，進(jìn)入?yún)��?shù)輸入頁(yè)面，選擇執(zhí)行的目標(biāo)設(shè)備，輸入?yún)��?shù)后，點(diǎn)擊立即執(zhí)行完成運(yùn)維場(chǎng)景所需要執(zhí)行的運(yùn)維操作。

　　自動(dòng)化告警處理

　　傳統(tǒng)告警處理，主要靠人工值守進(jìn)行操作，告警響應(yīng)速度受到多方面因素的制約，如告警信息發(fā)布及時(shí)性，運(yùn)維人員響應(yīng)及時(shí)性，運(yùn)維人員對(duì)系統(tǒng)熟悉程度等;一旦運(yùn)維人員錯(cuò)過了告警，本來有很簡(jiǎn)單有效的運(yùn)維操作沒有被執(zhí)行，就可能導(dǎo)致系統(tǒng)故障。

　　自動(dòng)化運(yùn)維工具通過告警消息自動(dòng)觸發(fā)故障處理流程，主動(dòng)高效地識(shí)別和解決故障，極大的提升運(yùn)維對(duì)故障的響應(yīng)速度和縮短故障時(shí)間。

　　快速高效地識(shí)別、解決和消除服務(wù)中斷的根源

　　通過工具來查看、管理、診斷和解決問題

　　整合運(yùn)維團(tuán)隊(duì)積累的、廠商的專業(yè)工具和知識(shí)來加速事件和問題的診斷和解決

　　自動(dòng)進(jìn)行故障問題定位并啟用對(duì)應(yīng)

　　一鍵快速診斷定位性能問題：

　　I/O性能問題

　　并發(fā)問題

　　低效SQL或者高負(fù)載SQL

　　對(duì)象爭(zhēng)用

　　鎖阻塞或HANG

　　運(yùn)維管理人員可以通過自動(dòng)化工具，根據(jù)告警觸發(fā)或手工調(diào)度診斷流程，自動(dòng)化工具自動(dòng)進(jìn)入診斷模塊，首先自動(dòng)判斷系統(tǒng)所存在問題:如IO問題、并發(fā)堵塞問題、低效SQL或高負(fù)載SQL問題、hang等。自動(dòng)化工具根據(jù)問題類型自動(dòng)調(diào)度預(yù)定處理流程或方案(預(yù)定處理腳本集)，最后返回診斷結(jié)果。

　　3.自動(dòng)可視化發(fā)布

　　隨著云化后機(jī)器數(shù)十倍的增長(zhǎng)，傳統(tǒng)“煙囪式”系統(tǒng)應(yīng)用部署模式耗時(shí)耗力，并且手動(dòng)發(fā)布出錯(cuò)的機(jī)率也非常大，我們嘗試引入互聯(lián)網(wǎng)自動(dòng)配置部署工具SaltStack，并考慮到SaltStack無WEB配置界面的缺點(diǎn)，在其外面定制開發(fā)了一層WEB可視化界面，從而實(shí)現(xiàn)了云化系統(tǒng)下自動(dòng)化可視化部署。

　　1)自動(dòng)化配置管理平臺(tái)SaltStack整體架構(gòu)

　　SaltStack是一個(gè)服務(wù)器基礎(chǔ)架構(gòu)集中化配置管理平臺(tái)，具備配置管理、遠(yuǎn)程執(zhí)行、監(jiān)控等功能，易于安裝使用，便于擴(kuò)展，可支撐管理上萬臺(tái)服務(wù)器或者虛擬機(jī)。依托云計(jì)算平臺(tái)資源池實(shí)施部署了SaltStack管理平臺(tái)。截至目前，SaltStack管理共計(jì)47套Linux系統(tǒng)，涵蓋測(cè)試域36套系統(tǒng)以及生產(chǎn)域11套系統(tǒng)，并且還在不斷的擴(kuò)展。基于C/S架構(gòu)，劃分為主控端和被控端，分別稱為Master和Minion。兩者基于證書認(rèn)證，安全可靠，其整體架構(gòu)如下：

　　2)SaltStack安裝配置

　　SaltStack可采用多種方式安裝，通過源碼安裝，將SaltStackMaster部署在RHEL6.5主機(jī)，啟動(dòng)Master進(jìn)程，并在全部受控機(jī)安裝SaltStack，啟動(dòng)Minion進(jìn)程。

　　Master和Minion在通信時(shí)需要進(jìn)行認(rèn)證，因此需在/etc/salt/master中配置Master節(jié)點(diǎn)的IP地址，在/etc/salt/minion中指明Master端的地址以及本機(jī)的唯一標(biāo)示。這樣在Master端認(rèn)證和統(tǒng)一配置時(shí)可以通過唯一標(biāo)示進(jìn)行。配置文件使用YAML$key:$value格式。

　　3)SaltStack應(yīng)用

　　在我們的業(yè)務(wù)系統(tǒng)中，主要按照操作系統(tǒng)以及應(yīng)用進(jìn)行分組，具體分組方式如下：

　　cat/etc/salt/master.d/nodegroup.conf nodegroups: redhatDatabase:‘redhat-db’ redhatAPP:‘redhat-app’ suseAPP:‘suse-app’ suseDatabase:‘suse-db’

　　受控機(jī)器的信息展現(xiàn)是通過grain組件進(jìn)行展現(xiàn)的，基本使用方法如下：

　　salt'redhat-db1'grains.ls查看grains分類

　　salt'redhat-db1'grains.items查看grains所有信息

　　salt'redhat-db1'grains.itemosrelease查看grains某個(gè)信息

　　4)可視化界面發(fā)布

　　通過在SaltStack外部，定制開發(fā)WEB界面，使得整個(gè)發(fā)布部署過程和發(fā)布結(jié)果全部可視化，具體的應(yīng)用步驟如下圖所示：

　　目前在多臺(tái)服務(wù)器上實(shí)現(xiàn)了并行批量執(zhí)行命令，根據(jù)不同業(yè)務(wù)特性進(jìn)行配置集中化管理、分發(fā)文件、采集服務(wù)器數(shù)據(jù)、操作系統(tǒng)基礎(chǔ)及軟件包管理等。

　　4、自動(dòng)化數(shù)據(jù)管理

　　云架構(gòu)下的IT系統(tǒng)越來越多，數(shù)據(jù)庫(kù)管理員需要面對(duì)成百上千的數(shù)據(jù)庫(kù)，另外隨著云架構(gòu)下的大數(shù)據(jù)平臺(tái)等技術(shù)的不斷深入，數(shù)據(jù)存儲(chǔ)將邁入EB級(jí)別，傳統(tǒng)手工數(shù)據(jù)管理的難度越來越大。同時(shí)云架構(gòu)中出于開發(fā)、測(cè)試、培訓(xùn)以及數(shù)據(jù)對(duì)外共享變現(xiàn)等環(huán)節(jié)需要從生產(chǎn)環(huán)境中同步和遷移大量數(shù)據(jù)，其中亦會(huì)涉及大量用戶隱私數(shù)據(jù)。而之前整體IT系統(tǒng)數(shù)據(jù)流和業(yè)務(wù)流的關(guān)系不太清晰，業(yè)務(wù)數(shù)據(jù)可視化展示程度很低，缺少可視化的企業(yè)整體數(shù)據(jù)地圖，對(duì)于數(shù)據(jù)的維護(hù)困難重重。

　　1)云架構(gòu)下數(shù)據(jù)管理規(guī)劃

　　為解決傳統(tǒng)數(shù)據(jù)管理上的痛點(diǎn)，讓數(shù)據(jù)管理相關(guān)工作更加標(biāo)準(zhǔn)化和流程化，我們借鑒國(guó)內(nèi)外IT業(yè)界先進(jìn)的數(shù)據(jù)管理和運(yùn)營(yíng)經(jīng)驗(yàn)，著手在數(shù)據(jù)管理領(lǐng)域的自動(dòng)化運(yùn)營(yíng)工具作出了規(guī)劃。整體規(guī)劃如下：

　　在此規(guī)劃的基礎(chǔ)上，著手建設(shè)了在云架構(gòu)下的數(shù)據(jù)安全管理以及數(shù)據(jù)生命周期管理兩個(gè)主要運(yùn)營(yíng)場(chǎng)景的自動(dòng)化工具化建設(shè)，其他還處在建設(shè)階段。

　　2)云架構(gòu)下數(shù)據(jù)生命周期管理

　　根據(jù)核心生產(chǎn)系統(tǒng)中數(shù)據(jù)的特點(diǎn)建立多層次數(shù)據(jù)存儲(chǔ)體系，將用戶訪問頻率較低的遠(yuǎn)期歷史數(shù)據(jù)按規(guī)劃從生產(chǎn)環(huán)境轉(zhuǎn)移到歷史數(shù)據(jù)中心和大數(shù)據(jù)平臺(tái)中，在不影響絕大部分用戶應(yīng)用感知的情況下，有效管控系統(tǒng)整體數(shù)據(jù)增長(zhǎng)，既降低系統(tǒng)運(yùn)營(yíng)成本，又滿足最終用戶的數(shù)據(jù)需求。我們的數(shù)據(jù)生命周期管理自動(dòng)化工具，由數(shù)據(jù)管理員針對(duì)不同種類的數(shù)據(jù)梳理的數(shù)據(jù)生命周期策略進(jìn)行可視化的管理，以自動(dòng)化方式按不同周期識(shí)別歷史數(shù)據(jù)并將歷史數(shù)據(jù)完整地遷移到歷史數(shù)據(jù)中心或其他大數(shù)據(jù)平臺(tái)中。

　　通過作業(yè)化自動(dòng)化的思路，以自動(dòng)化平臺(tái)方式實(shí)現(xiàn)數(shù)據(jù)生命周期管理的全程，減少人力在策略管理、數(shù)據(jù)遷移和數(shù)據(jù)清理中的人工投入，主要目標(biāo)在于：

　　策略管理：在平臺(tái)中對(duì)數(shù)據(jù)生命周期管理策略進(jìn)行有效管理;策略定義包括數(shù)據(jù)生命周期定義，數(shù)據(jù)遷移策略定義，數(shù)據(jù)清理策略定義;定義數(shù)據(jù)生命周期作業(yè)，定時(shí)進(jìn)行數(shù)據(jù)生命周期作業(yè)調(diào)度

　　數(shù)據(jù)遷移：根據(jù)平臺(tái)中的配置的數(shù)據(jù)生命周期策略定義，請(qǐng)理作業(yè)實(shí)施數(shù)據(jù)的自動(dòng)化遷移，數(shù)據(jù)遷移過程無需人工干預(yù)，不同數(shù)據(jù)平臺(tái)間數(shù)據(jù)遷移

　　數(shù)據(jù)清理：數(shù)據(jù)重要程度，清理過程可以通過配置為自動(dòng)執(zhí)行和人工確認(rèn)執(zhí)行。根據(jù)平臺(tái)中的配置的數(shù)據(jù)生命周期策略定義，作業(yè)實(shí)施數(shù)據(jù)的自動(dòng)化清理

　　3)云架構(gòu)下數(shù)據(jù)安全管理

　　根據(jù)生產(chǎn)系統(tǒng)中敏感數(shù)據(jù)分布情況，建立敏感數(shù)據(jù)策略化管理。在數(shù)據(jù)從生產(chǎn)環(huán)境中向未安全環(huán)境，包括開發(fā)、測(cè)試、培訓(xùn)和對(duì)外數(shù)據(jù)共享等，進(jìn)行數(shù)據(jù)遷移和同步的過程中，因應(yīng)數(shù)據(jù)安全管理員制定的敏感策略對(duì)數(shù)據(jù)進(jìn)行自動(dòng)化安全脫敏，減少敏感數(shù)據(jù)外泄的可能。

　　目前數(shù)據(jù)安全自動(dòng)化管理工具，實(shí)現(xiàn)從敏感數(shù)據(jù)識(shí)別，脫敏策略配置，數(shù)據(jù)遷移配置，以及數(shù)據(jù)在線和離線脫敏全程，自動(dòng)化安全地將數(shù)據(jù)從生產(chǎn)環(huán)境向非安全環(huán)境遷移，同時(shí)在遷移過程中實(shí)施敏感數(shù)據(jù)脫敏。

　　分析篇：利用大數(shù)據(jù)實(shí)時(shí)分析助力運(yùn)維

　　數(shù)據(jù)是金礦，隨著云化的深入，價(jià)值數(shù)據(jù)之間分散到海量機(jī)器中，需要采用大數(shù)據(jù)技術(shù)進(jìn)行集中化處理，并助力運(yùn)維。我們公司進(jìn)行了積極嘗試，引入flume+kafka+spark+分布式內(nèi)存庫(kù)redis等開源技術(shù)自主進(jìn)行大數(shù)據(jù)運(yùn)維分析，取得了一定的效果。

　　整體架構(gòu)如下圖所示�？紤]到來自業(yè)務(wù)系統(tǒng)的數(shù)據(jù)是多元化的，既包括了軟、硬件基礎(chǔ)設(shè)施日志數(shù)據(jù)，也包括各類應(yīng)用服務(wù)的日志數(shù)據(jù)，這兩類日志數(shù)據(jù)通過主機(jī)和分布式軟件代理服務(wù)、分布式消息采集服務(wù)和分析服務(wù)處理后，以流數(shù)據(jù)的方式轉(zhuǎn)給大數(shù)據(jù)平臺(tái)和報(bào)表平臺(tái)：

　　分布式數(shù)據(jù)(應(yīng)用日志等)采集

　　整個(gè)分布式采集分為如下四個(gè)部分：

　　數(shù)據(jù)采集：負(fù)責(zé)從各個(gè)節(jié)點(diǎn)上實(shí)時(shí)采集日志數(shù)據(jù)，可以指定目錄或文件，通過flume實(shí)現(xiàn)，僅增量采集數(shù)據(jù)。

　　數(shù)據(jù)接入：由于上述采集數(shù)據(jù)的速度和數(shù)據(jù)處理的速度不一定同步，增加分布式消息曾作為緩沖，防止丟失數(shù)據(jù)，采用kafka。

　　流式處理：對(duì)采集的數(shù)據(jù)進(jìn)行實(shí)時(shí)分析，選用spark-streaming+redis實(shí)現(xiàn)。

　　數(shù)據(jù)輸出：對(duì)分析結(jié)果存儲(chǔ)在mysql數(shù)據(jù)庫(kù)中，并進(jìn)行告警展示。

　　以往，業(yè)務(wù)支撐網(wǎng)中的日志分布在各服務(wù)器上，每次檢索要逐一登陸到各服務(wù)器操作，嚴(yán)重影響效率;同時(shí)，日志留存于操作系統(tǒng)本地，會(huì)受到存儲(chǔ)空間限制而循環(huán)覆蓋，導(dǎo)致重要數(shù)據(jù)丟失;由于對(duì)關(guān)鍵日志缺乏保護(hù)，也給監(jiān)控、審計(jì)帶來諸多困難。

　　隨著業(yè)務(wù)發(fā)展，來自硬件、操作系統(tǒng)和中間件的日志量不斷膨脹，獨(dú)立而分散的日志管理模式已不能滿足日益增長(zhǎng)的維護(hù)需求，特別在事件回溯、問題分析及報(bào)表統(tǒng)計(jì)相關(guān)工作中，其基礎(chǔ)數(shù)據(jù)均源自這些紛繁蕪雜的日志單元，亟需形成統(tǒng)一管理、綜合分析、集中展現(xiàn)的新型一體化管理機(jī)制。為此一直進(jìn)行著日志集中化改造的嘗試。

　　起初，以HTTP服務(wù)器日志統(tǒng)計(jì)為例，傳統(tǒng)解決方式是定期(按5分鐘、小時(shí)或天)截?cái)嗳罩�，然后通過FTP上傳到一臺(tái)服務(wù)器統(tǒng)一處理，在有些日志的計(jì)算處理前需要考慮日志排序問題。這樣的日志同步可以支持幾臺(tái)到幾十臺(tái)規(guī)模的并發(fā)服務(wù)，但當(dāng)管理的服務(wù)器達(dá)到幾十臺(tái)，而有大量的服務(wù)器中間會(huì)有下線、上線或變更時(shí)，集中的日志定期同步更顯得難于管理，且日志同步要避開白天的高峰，往往需要用凌晨的低峰時(shí)段同步，24小時(shí)下來，上G的日志同步也是風(fēng)險(xiǎn)很高的操作。而成為瓶頸的日志排序合并操作也會(huì)妨礙其他后續(xù)計(jì)算的周期。其邏輯架構(gòu)如下所示。

　　目前實(shí)現(xiàn)了應(yīng)用分布但日志集中的遠(yuǎn)程存儲(chǔ)模式，通過UDP協(xié)議實(shí)現(xiàn)小局域網(wǎng)內(nèi)的日志廣播，然后在多臺(tái)匯聚服務(wù)器上實(shí)現(xiàn)各種日志的并發(fā)計(jì)算。如圖所示：

　　為保證日志流傳輸?shù)目煽啃裕瑢?duì)整個(gè)傳輸鏈進(jìn)行了改造，實(shí)現(xiàn)了多個(gè)特性：非阻塞的適配器、網(wǎng)絡(luò)劃分、負(fù)載均衡、傳輸高可用性、傳輸監(jiān)控能力及可以動(dòng)態(tài)調(diào)整的Push/Polling模式。

　　無論是網(wǎng)絡(luò)設(shè)備、應(yīng)用服務(wù)器還是中間件，其日志需要與Flume節(jié)點(diǎn)對(duì)接，這就涉及到協(xié)議適配的問題，為此專門針對(duì)企業(yè)總線(eBus、UAP)、前端Web容器及交易中間件配置協(xié)議適配驅(qū)動(dòng)，將日志以流的方式傳輸給Flume代理，協(xié)議適配層提供了較豐富的協(xié)議適配驅(qū)動(dòng)，能夠支持來自各層面基礎(chǔ)設(shè)施的日志數(shù)據(jù)對(duì)接，目前已成功接入的基本組件有交換機(jī)、負(fù)載均衡器、各刀片服務(wù)器操作系統(tǒng)及應(yīng)用程序，如圖所示：

　　當(dāng)采用適配器連接Flume代理時(shí)，應(yīng)用服務(wù)會(huì)調(diào)用異步附加組件AsyncAppender輸出日志流，如果Flume代理宕機(jī)，且無備份節(jié)點(diǎn)時(shí)，會(huì)導(dǎo)致應(yīng)用服務(wù)器阻塞，我們針對(duì)一些適配器配置了non-Blocking特性參數(shù)，當(dāng)啟用此參數(shù)時(shí)，即使日志流寫入失敗，不會(huì)影響正常業(yè)務(wù)運(yùn)行。

　　為確�；�于UDP廣播的傳輸模式不會(huì)形成網(wǎng)絡(luò)風(fēng)暴，我們按照不同的業(yè)務(wù)范疇、不同的組件類型劃分子網(wǎng)，同一子網(wǎng)內(nèi)的應(yīng)用服務(wù)器僅與當(dāng)前子網(wǎng)的Flume代理通信。在高可用性方面，應(yīng)用服務(wù)器以UDP協(xié)議在子網(wǎng)內(nèi)廣播日志數(shù)據(jù)，UDP包被多個(gè)Flume代理節(jié)點(diǎn)截獲，某一時(shí)刻僅有一個(gè)Flume Agent處于Active狀態(tài)，其他為Standby，當(dāng)Flume節(jié)點(diǎn)宕機(jī)時(shí)，其他節(jié)點(diǎn)可以無縫接替繼續(xù)工作，所有Flume Agent通過Flume Master節(jié)點(diǎn)管理，實(shí)現(xiàn)主備接管和配置同步功能。如圖所示：

　　(灰色框?yàn)閭錂C(jī))

　　為便于維護(hù)人員及時(shí)了解日志傳輸?shù)墓ぷ鳡顟B(tài)，對(duì)Flume的相關(guān)命令進(jìn)行了封裝，在統(tǒng)一界面上展現(xiàn)來自Flume不同端口的數(shù)據(jù)接收情況。

　　對(duì)于超大規(guī)模的營(yíng)業(yè)廳前端用戶交互日志采集，采用UDP、FTP方式可能會(huì)導(dǎo)致過高的網(wǎng)絡(luò)、磁盤I/O資源消耗，因此首先保證整個(gè)架構(gòu)過程中，除在匯聚服務(wù)器和日志中心外的Flume節(jié)點(diǎn)上均不產(chǎn)生文件落地，僅在匯聚服務(wù)器中實(shí)現(xiàn)了對(duì)來自多個(gè)Flume代理的數(shù)據(jù)聚合和排序。同時(shí)在業(yè)務(wù)高峰時(shí)段，日志采集處理能力有限，F(xiàn)lume代理會(huì)從Pushing模式切換為Pulling模式，即從采集轉(zhuǎn)為采樣。

　　2、實(shí)時(shí)數(shù)據(jù)聚合+分組

　　利用大數(shù)據(jù)集中處理平臺(tái)的處理流程主要分兩部分，通過消息隊(duì)列處理Flume采集的日志，再通過ElasticSearch建立索引，最終將數(shù)據(jù)、索引導(dǎo)入在mysql集群。如下：

　　大數(shù)據(jù)平臺(tái)主要分析營(yíng)業(yè)廳與用戶交互日志，其中包括實(shí)時(shí)的用戶體驗(yàn)、服務(wù)器請(qǐng)求記錄。用戶體驗(yàn)日志是用戶在瀏覽器中每一步操作的性能評(píng)估，主要包括用戶每一步操作的名稱(如點(diǎn)擊按鈕、鍵盤錄入、下拉框的選擇、復(fù)選框的勾選及頁(yè)面刷新等);用戶操作整體響應(yīng)時(shí)間及其構(gòu)成部分：客戶端響應(yīng)時(shí)間(包括頁(yè)面元素渲染時(shí)間、頁(yè)面JavaScript腳本執(zhí)行時(shí)間)、網(wǎng)絡(luò)耗時(shí)(包括網(wǎng)絡(luò)中的傳輸時(shí)延及第三方內(nèi)容服務(wù)CDN的處理時(shí)間)、服務(wù)器運(yùn)行時(shí)間。通過用戶體驗(yàn)日志可以了解到用戶每一步操作的感知狀況，準(zhǔn)確了解性能故障對(duì)用戶操作的影響;此外，用戶操作和用戶請(qǐng)求是相互關(guān)聯(lián)的，通過關(guān)聯(lián)關(guān)系可以找到每一步用戶操作的具體含義，如(某一步操作是在繳費(fèi)業(yè)務(wù)的錄入用戶號(hào)碼操作)。

　　然后就是對(duì)用戶操作業(yè)務(wù)聚合，即按時(shí)間順序、用戶操作的業(yè)務(wù)名稱、用戶號(hào)碼等對(duì)用戶真實(shí)的操作情景予以重建，這樣做的好處是從整體上了解某一筆業(yè)務(wù)的操作繁瑣程度(難易度、友好性);了解某一筆業(yè)務(wù)在哪一步較慢，是慢在網(wǎng)絡(luò)層面、客戶端層面、服務(wù)器層面還是用戶自身原因(如間歇性停留)導(dǎo)致的;了解業(yè)務(wù)分布情況及成功率、轉(zhuǎn)化率等。為確保業(yè)務(wù)聚合的并行計(jì)算高效，我們采取了spark流處理機(jī)制完成。目前主要應(yīng)用了如下幾個(gè)場(chǎng)景：

　　場(chǎng)景1：以下圖為例，通過大數(shù)據(jù)的數(shù)據(jù)聚合+分組手段，實(shí)現(xiàn)對(duì)用戶行為的模式匹配，將多個(gè)操作歸結(jié)到一筆業(yè)務(wù)中，實(shí)現(xiàn)用戶體驗(yàn)不好根本原因是IT原因造成還是非IT因素造成(用戶問題、營(yíng)業(yè)員操作問題)：

　　場(chǎng)景2：結(jié)合大數(shù)據(jù)的分析，掌握用戶的操作規(guī)律、操作習(xí)慣，并基于這些分析進(jìn)行頁(yè)面優(yōu)化，如在合適位置投放廣告，發(fā)布符合大眾需求的產(chǎn)品與優(yōu)惠：

　　場(chǎng)景3：實(shí)現(xiàn)基于業(yè)務(wù)監(jiān)控的入侵檢測(cè)機(jī)制，我們基于集中日志分析，利用大數(shù)據(jù)技術(shù)實(shí)現(xiàn)基于業(yè)務(wù)聚合的CC攻擊分析方法，將用戶操作與瀏覽器請(qǐng)求建立關(guān)聯(lián)，首先將URI請(qǐng)求按用戶操作聚合，形成用戶操作序列，再按照時(shí)間先后順序及一定的業(yè)務(wù)規(guī)則將用戶操作聚合為業(yè)務(wù)單元，通過對(duì)業(yè)務(wù)單元數(shù)據(jù)分析判斷是否存在入侵檢測(cè)。大大提高了針對(duì)仿真式DDos攻擊的鑒別準(zhǔn)確度。

　　下圖是近期發(fā)現(xiàn)的感染木馬病毒的終端列表：

　　3、深入性能診斷

　　我們基于集中日志實(shí)時(shí)分析，可用于性能診斷等場(chǎng)景，并總結(jié)了一些寶貴經(jīng)驗(yàn)：如網(wǎng)絡(luò)故障關(guān)聯(lián)分析和診斷、診斷企業(yè)總線調(diào)用外部域時(shí)發(fā)生的故障、基于接口報(bào)文的后端交易調(diào)優(yōu)、針對(duì)RPC的性能分析等。

　　1)網(wǎng)絡(luò)故障診斷

　　網(wǎng)絡(luò)延遲故障一般可以從用戶體驗(yàn)的網(wǎng)絡(luò)耗時(shí)一項(xiàng)直接診斷定位，但有時(shí)很難一下子定位，也需要從用戶請(qǐng)求中，如從HTTP服務(wù)器和WAS服務(wù)器的耗時(shí)份額對(duì)比中推導(dǎo)，亦可以從用戶請(qǐng)求服務(wù)器代碼路徑中推導(dǎo)出來。

　　從下圖1看，某用戶請(qǐng)求在IHS(HTTP服務(wù)器)上耗費(fèi)的時(shí)間為14.69s，而端到端路徑分析，在WAS(APP服務(wù)器)上的耗費(fèi)時(shí)間為2.57ms，因此分析可知時(shí)間主要耗費(fèi)在HTTP服務(wù)器上，而HTTP服務(wù)器主要作為一個(gè)代理與用戶終端交互，因此分析得知有2種可能：在終端用戶到HTTP服務(wù)器之間的鏈路上出現(xiàn)了網(wǎng)絡(luò)故障，或HTTP服務(wù)器出現(xiàn)了性能問題，而經(jīng)過監(jiān)控發(fā)現(xiàn)其他業(yè)務(wù)運(yùn)行均正常，HTTP服務(wù)器線程池使用正常，如圖2所示，因此通過排除法得知網(wǎng)絡(luò)故障可能性較大。

　　圖1 端到端路徑分析

　　圖2 HTTP服務(wù)器的線程池使用情況

　　另外通過服務(wù)器響應(yīng)字節(jié)數(shù)進(jìn)一步證實(shí)之前的推論，返回大小相比其他同類請(qǐng)求來說較大，如下圖所示。

　　2)基于接口報(bào)文進(jìn)行的后端交易優(yōu)化

　　我們CRM交易處理程序基于C/C++實(shí)現(xiàn)，這導(dǎo)致交易中間件無法向基于JVM的前端Web服務(wù)一樣實(shí)現(xiàn)運(yùn)行時(shí)環(huán)境注入并動(dòng)態(tài)改變監(jiān)控行為，只能通過捕獲應(yīng)用程序觸發(fā)的操作系統(tǒng)底層業(yè)務(wù)邏輯實(shí)現(xiàn)，這種情況下無法實(shí)現(xiàn)前端與后端的單筆交易關(guān)聯(lián)。為解決此問題，首先對(duì)CICS應(yīng)用服務(wù)進(jìn)程啟動(dòng)多線程跟蹤，將truss日志輸出流重定向到UDP，發(fā)送給外部服務(wù)器，truss會(huì)跟蹤到一些極基礎(chǔ)的函數(shù)調(diào)用，使用truss跟蹤的好處是，當(dāng)和被跟蹤進(jìn)程依附和解除依附時(shí)，對(duì)被跟蹤的進(jìn)程不會(huì)造成影響，因此可以在生產(chǎn)環(huán)境中使用。此外，可以對(duì)CICS連接到Oracle的會(huì)話，在數(shù)據(jù)庫(kù)中啟動(dòng)10046事件跟蹤，跟蹤數(shù)據(jù)庫(kù)的調(diào)用軌跡，這種方式的好處是：填補(bǔ)了CICS跟蹤的空白，實(shí)現(xiàn)了對(duì)業(yè)務(wù)的梳理;壞處是：只能小范圍開啟，需要在生產(chǎn)隔離出單獨(dú)的一套中間件，并在此環(huán)境中回放報(bào)文處理過程。

　　下圖是通過啟用數(shù)據(jù)庫(kù)10046事件跟蹤后，梳理出的合約機(jī)校驗(yàn)接口的業(yè)務(wù)邏輯(部分)。

　　服務(wù)篇：建立面向云服務(wù)的運(yùn)維架構(gòu)

　　目前我們的運(yùn)維模式是基于ITIL的，從服務(wù)臺(tái)、時(shí)間管理、變更管理、可用性管理、容量管理、CMDB等思路逐步建設(shè)整個(gè)系統(tǒng)，這種運(yùn)維思路在傳統(tǒng)架構(gòu)下沒問題，但在云計(jì)算下大規(guī)模運(yùn)維的時(shí)候，越來越難以應(yīng)對(duì)，或者說過多的聚焦于流程和規(guī)范的情況下，很難提升運(yùn)維敏捷性和精細(xì)性。當(dāng)前，IT支撐系統(tǒng)正在向資源池、SOA架構(gòu)快速演進(jìn)，系統(tǒng)支撐能力逐步具備了服務(wù)化的能力。通過對(duì)系統(tǒng)能力組件化和服務(wù)化，并配合系統(tǒng)彈性伸縮等能力，將支撐系統(tǒng)的能力以“服務(wù)”的形式提供，屏蔽內(nèi)部過多的細(xì)節(jié)，可以實(shí)現(xiàn)“IT即服務(wù)的新型敏捷支撐與運(yùn)維模式。

　　為適應(yīng)“IT即服務(wù)”的新型運(yùn)維模式，嘗試打破原有按照專業(yè)(主機(jī)、存儲(chǔ)、數(shù)據(jù)庫(kù)、中間件、網(wǎng)絡(luò)……)和項(xiàng)目劃分的組織架構(gòu)，按照資源池運(yùn)營(yíng)管理模式進(jìn)行架構(gòu)重構(gòu)，把運(yùn)維工作劃分為服務(wù)運(yùn)營(yíng)、資源運(yùn)營(yíng)兩個(gè)核心維度，并以此為核心組織進(jìn)行基礎(chǔ)設(shè)施層面的構(gòu)建和上層的管理運(yùn)營(yíng)，如下：

　　經(jīng)過上述調(diào)整，大大降低了之前各個(gè)專業(yè)之間協(xié)同難度以及不同專業(yè)間的專業(yè)壁壘，例如支撐一個(gè)項(xiàng)目，原來需要主機(jī)組提供主機(jī)資源、網(wǎng)絡(luò)組提供網(wǎng)絡(luò)、數(shù)據(jù)庫(kù)組提供數(shù)據(jù)庫(kù)等，現(xiàn)在提前建好資源池，資源池的運(yùn)維人員通過云管理平臺(tái)幾乎可實(shí)現(xiàn)一切底層設(shè)施，每個(gè)人對(duì)各個(gè)專業(yè)門檻也大大降低了要求，適應(yīng)了大規(guī)模環(huán)境下的運(yùn)維要求。

　　考慮到資源池初始階段還有很多傳統(tǒng)架構(gòu)和云架構(gòu)并存，且資源池需要提前建設(shè)，上述劃分僅適應(yīng)運(yùn)營(yíng)階段需要，我們?cè)谶\(yùn)營(yíng)團(tuán)隊(duì)中橫向構(gòu)建了跨專業(yè)的虛擬團(tuán)隊(duì)，作為項(xiàng)目小組，人員跨資源運(yùn)營(yíng)和服務(wù)運(yùn)營(yíng)的成員組成，例如擴(kuò)容項(xiàng)目組、工程項(xiàng)目組、業(yè)務(wù)連續(xù)性項(xiàng)目組等，作為臨時(shí)需要時(shí)的一個(gè)扁平化團(tuán)隊(duì)，如下圖所示：

　　通過上述組織架構(gòu)調(diào)整，結(jié)合我們?cè)谫Y源池管理平臺(tái)實(shí)現(xiàn)的IAAS和PAAS的自動(dòng)管理功能，大大降低了運(yùn)維難度，同時(shí)規(guī)避了繁瑣的運(yùn)維流程，初步實(shí)現(xiàn)了敏捷運(yùn)維能力。同時(shí)根據(jù)測(cè)算，在人員配備上，如果按照傳統(tǒng)運(yùn)維架構(gòu)，2000臺(tái)服務(wù)器規(guī)模需要不同專業(yè)運(yùn)維人員12人以上，而采用新的運(yùn)維架構(gòu)，只需3-4人即可。

　　上述是在組織架構(gòu)上適應(yīng)云服務(wù)的運(yùn)維，在技術(shù)上，我們公司積極推進(jìn)企業(yè)級(jí)資源池、第三代CRM的IAAS和PAA融合架構(gòu)建設(shè)，實(shí)現(xiàn)應(yīng)用節(jié)點(diǎn)容量通過服務(wù)方式自動(dòng)擴(kuò)展，做到集中統(tǒng)一管控，深入運(yùn)維提升核心掌控能力，目前本項(xiàng)目正在建設(shè)中，如下圖所示：

　　效果和后續(xù)計(jì)劃

　　通過近兩年的持續(xù)探索，引入了較多的互聯(lián)網(wǎng)開源運(yùn)維工具，并經(jīng)過定制化改造，目前已經(jīng)初步搭建了面向云化架構(gòu)下的系統(tǒng)運(yùn)維架構(gòu)。通過完善相應(yīng)的監(jiān)控、維護(hù)工具和數(shù)據(jù)分析，簡(jiǎn)化了系統(tǒng)運(yùn)維難度，大大提升了系統(tǒng)維護(hù)效率;另外通過系統(tǒng)建設(shè)，運(yùn)維人員接觸到很多新的互聯(lián)網(wǎng)化運(yùn)維工具，人員自身的能力和工作積極性有了較大提升;而新工程項(xiàng)目建設(shè)時(shí)，。因?yàn)閺母鲗蛹?jí)有了可視化操作工具，項(xiàng)目建設(shè)難度大大降低，減少了較多的項(xiàng)目協(xié)調(diào)工作，人員投入也從之前的8-9人變?yōu)?-3人承擔(dān)。

　　盡管目前引入了較多的云化運(yùn)維工作，但目前各個(gè)工具還相對(duì)比較分散，未來我們計(jì)劃對(duì)各個(gè)運(yùn)維工具統(tǒng)一建設(shè)，能夠集中到一個(gè)統(tǒng)一的操作平臺(tái)上，各個(gè)工具也能夠作為一個(gè)整體相互協(xié)調(diào)運(yùn)作。