電商行業(yè)在中國(guó)已經(jīng)走過(guò)很多年頭，卻依然沒(méi)有停下迅猛發(fā)展的腳步，其中一些垂直領(lǐng)域的前景和市場(chǎng)仍然可觀，例如化妝品電商。作為女性的“必需品”，網(wǎng)購(gòu)化妝品市場(chǎng)規(guī)模一直都在保持增長(zhǎng)，作為國(guó)內(nèi)較早成立并且首個(gè)赴美上市的垂直化妝品電商，聚美優(yōu)品可能經(jīng)歷整個(gè)市場(chǎng)的不斷進(jìn)化，然而對(duì)這種變革感觸最深的，恐怕要數(shù)聚美優(yōu)品的運(yùn)維工程師們。

 

 

    2013年時(shí)，聚美優(yōu)品已經(jīng)成立有3年之久，在這一年，他的全年銷(xiāo)售額突破60億元，這是個(gè)很高的數(shù)字，然而在聚美優(yōu)品級(jí)運(yùn)維工程師崔星眼里，這只是個(gè)開(kāi)始。他回憶到，在2013年聚美優(yōu)品的監(jiān)控規(guī)模還小于200臺(tái)，監(jiān)控指標(biāo)只有不到5000個(gè)，而這個(gè)數(shù)量在短短一年之內(nèi)增加1000臺(tái)、五萬(wàn)個(gè)指標(biāo)，當(dāng)大家都認(rèn)為這個(gè)發(fā)展會(huì)放緩時(shí)，直到今日，聚美優(yōu)品監(jiān)控的指標(biāo)已經(jīng)超過(guò)了五十萬(wàn)個(gè)，架構(gòu)也從最初的Nagios+Ganglia變?yōu)榱巳缃竦腪abbix+CMDB。

 

    這樣的改變是如何發(fā)生的？在早期，聚美優(yōu)品遇到遇到過(guò)很多的問(wèn)題：

 

    1、監(jiān)控系統(tǒng)自身水平擴(kuò)展能力差：沒(méi)有使用登錄式，水平拓展也不是很好

 

    2、不利于自動(dòng)化：指標(biāo)更新很復(fù)雜，配置一個(gè)指標(biāo)，要更改指標(biāo)項(xiàng)目，監(jiān)控項(xiàng)目，這時(shí)候需要通過(guò)工具批量執(zhí)行

 

    3、告警策略的維護(hù)：變更代價(jià)太大

 

    4、監(jiān)控指標(biāo)展示不太直觀

 

    5、數(shù)據(jù)采集也不統(tǒng)一…………

 

    隨著公司業(yè)務(wù)發(fā)展的變遷，為了解決問(wèn)題，聚美優(yōu)品意識(shí)到必須打造一個(gè)優(yōu)秀的監(jiān)控系統(tǒng)，而這個(gè)監(jiān)控系統(tǒng)應(yīng)具備的這樣的條件：

 

    強(qiáng)大的數(shù)據(jù)采集

 

    高效的告警策略

 

    個(gè)性化的告警設(shè)置

 

    多維度的數(shù)據(jù)展示

 

    可水平擴(kuò)展

 

    最終，聚美優(yōu)品找到一種新思路，CMDB+Zabbix，滿足優(yōu)秀監(jiān)控所具備的條件，最終成為自己開(kāi)發(fā)的運(yùn)維開(kāi)發(fā)平臺(tái)。

 

 

    我們先來(lái)看一下聚美這套全新的監(jiān)控平臺(tái)的體系架構(gòu)圖：
 

 

圖1 監(jiān)控平臺(tái)的體系架構(gòu)圖

 

    從圖中，我們可以看到有很多亮點(diǎn)：

 

    數(shù)據(jù)采集：agent自動(dòng)發(fā)現(xiàn)，主動(dòng)推送模式

 

    分布式監(jiān)控：監(jiān)控proxy可持續(xù)水平擴(kuò)展

 

    告警策略人性化：遞延報(bào)警，報(bào)警暫停，按時(shí)段發(fā)送不同類(lèi)型告警

 

    DashbOArd：多維度數(shù)據(jù)展示，Top指標(biāo)對(duì)比等功能

 

    自動(dòng)管理：自動(dòng)清除下限機(jī)器，自動(dòng)更新項(xiàng)目類(lèi)型

 

 

    在數(shù)據(jù)采集方面，基礎(chǔ)采集項(xiàng)全部采用自動(dòng)發(fā)現(xiàn)，無(wú)需配置，實(shí)時(shí)從CMDB抓取項(xiàng)目、環(huán)境、狀況等相關(guān)信息。拿到這些信息之后，再注冊(cè)到Server上面去，Server有相關(guān)的一系列匹配。與此同時(shí)，采用主動(dòng)模式上報(bào)監(jiān)控?cái)?shù)據(jù)，大幅度減輕監(jiān)控Server端的壓力。最后再禁用遠(yuǎn)程命令調(diào)用，保證安全高效。

 

    針對(duì)告警聚美優(yōu)品做了很多的優(yōu)化和設(shè)置：

 

    支持維護(hù)周期設(shè)置：想告警幾天就設(shè)置告警幾天，如果不想監(jiān)控，可以永久關(guān)閉；如果某臺(tái)機(jī)器凌晨五點(diǎn)不想告警的話，可以在這段時(shí)間進(jìn)行關(guān)閉。

 

    自定義告警類(lèi)型：可以通過(guò)短信或者郵件告知。

 

    告警列表：可以知道究竟有哪些告警現(xiàn)在沒(méi)有消除，持續(xù)了多長(zhǎng)時(shí)間，可以作為常規(guī)的考核可以是看持續(xù)性問(wèn)題的觀察。

 

    告警分析：通過(guò)一些定義很?chē)?yán)重的告警，分很多等級(jí)，不同的等級(jí)可以發(fā)送給運(yùn)維人員。

 

    告警遞延：第一次告警是運(yùn)維人員，如果運(yùn)維人員半個(gè)小時(shí)之后沒(méi)有處理，告警信息會(huì)上報(bào)給開(kāi)發(fā)人員或者是部門(mén)主管。
 

 

   圖2 支持告警恢復(fù)通知

 

    上面這張就是聚美優(yōu)品的告警周期維護(hù)的截圖，我們可以看出設(shè)置告警的時(shí)間，一些指標(biāo)的查看，問(wèn)題處理的時(shí)候，持續(xù)周期，警告時(shí)間，運(yùn)維人員等一系列內(nèi)容，都可以通過(guò)告警列表去知曉。

 

 

    一個(gè)監(jiān)控系統(tǒng)的好壞，很大程度上要看展示板的功能如何，聚美優(yōu)品的展示板就是他們的特色之一：

 

    項(xiàng)目指標(biāo)聚合展示：將業(yè)務(wù)中一些比較重要的內(nèi)容做展示，例如有20臺(tái)機(jī)器的數(shù)據(jù)，聚合展示就可以把這20臺(tái)機(jī)器做一些累加�？梢园迅信d趣放到總攬里面，聚合指標(biāo)分為幾類(lèi)，例如CPU、內(nèi)存，還有IR等。
 

 

圖3 Dashboard
 

    用戶自定義Dashboard：開(kāi)發(fā)人員和運(yùn)維人員可以根據(jù)自己的習(xí)慣進(jìn)行使用

 

    項(xiàng)目層級(jí)展示：當(dāng)項(xiàng)目很多時(shí)，可以歸類(lèi)已不同層級(jí)展示

 

    指標(biāo)對(duì)比分析：在遇到一些類(lèi)似大促這樣的情況時(shí)，假設(shè)有一百臺(tái)機(jī)器，通過(guò)指標(biāo)對(duì)比可以知道誰(shuí)的網(wǎng)卡最高，例如圖中我們看到藍(lán)色波動(dòng)，是不是這個(gè)時(shí)間段出現(xiàn)了一些異常，是配置錯(cuò)了？還是機(jī)器本身有問(wèn)題，可以通過(guò)對(duì)比指標(biāo)找出原因。
 

 

圖4 Top指標(biāo)實(shí)時(shí)統(tǒng)計(jì)

 

    Top指標(biāo)實(shí)時(shí)統(tǒng)計(jì)：實(shí)時(shí)展示某批機(jī)器下面的常規(guī)指標(biāo)，可以看到當(dāng)前最高指標(biāo)的情況。通過(guò)把一些常規(guī)指標(biāo)作為一個(gè)實(shí)時(shí)的展示在可以很清楚直觀的知道這一些項(xiàng)目下面機(jī)器的情況，例如一些流量，IO的情況。

 

 

    聚美優(yōu)品認(rèn)為，一個(gè)平臺(tái)的穩(wěn)定除了需要對(duì)硬件監(jiān)控之外，對(duì)于應(yīng)用的監(jiān)控同樣重要。

 

    使用聽(tīng)云App對(duì)聚美優(yōu)品APP進(jìn)行監(jiān)控：

 

 

    通過(guò)聽(tīng)云App對(duì)崩潰進(jìn)行分析，進(jìn)行不斷地bug修復(fù)，聚美優(yōu)品每迭代一個(gè)新的版本崩潰率都會(huì)有明顯的下降。

 

    劫持分析
 

 

圖5 劫持分析

 

    對(duì)于絕大多數(shù)的電子商務(wù)網(wǎng)站來(lái)說(shuō)，PC端業(yè)務(wù)有70%會(huì)轉(zhuǎn)移到移動(dòng)端，用戶越來(lái)越關(guān)注PC和移動(dòng)端的用戶體驗(yàn)。隨著直播的火爆，聚美優(yōu)品最近逐步加大了在直播上的業(yè)務(wù)。但隨之而來(lái)的可能就要去處理網(wǎng)絡(luò)劫持現(xiàn)象的攀升。

 

    1、通過(guò)使用聽(tīng)云App的劫持分析在全國(guó)范圍內(nèi)劫持比例在2個(gè)月下降50%。

 

    2、聚美會(huì)派專(zhuān)人每天將聽(tīng)云統(tǒng)計(jì)的崩潰原始數(shù)據(jù)導(dǎo)入平臺(tái)，再配合安排相關(guān)測(cè)試解決響應(yīng)Bug，跟蹤Bug處理進(jìn)度，半年來(lái)崩潰比例下降明顯，投訴率大幅下降，用戶粘度提升顯著。

 

    3、聽(tīng)云App提供的行業(yè)數(shù)據(jù)對(duì)指導(dǎo)優(yōu)化很有幫助，隨著直播業(yè)務(wù)的展開(kāi)，對(duì)標(biāo)行業(yè)趨勢(shì)很有必要。

 

 

    通過(guò)調(diào)查發(fā)現(xiàn)，一般有30%以上的用戶會(huì)因圖片體積過(guò)大而將APP進(jìn)行卸載。聚美移動(dòng)端在展示上存在較多的大圖，對(duì)用戶流量消耗比較大，通過(guò)聽(tīng)云App可對(duì)圖片體積進(jìn)行有效優(yōu)化。行業(yè)參考值圖片體積正常范圍在50KB以?xún)?nèi)，優(yōu)秀范圍小于20KB，聚美iOS版本中的圖片嘗試了WEBP格式，大幅提升了油畫(huà)效果。

 

 

    某一時(shí)期某廠商HTTPDNS接口的錯(cuò)誤率高于行業(yè)參考值，但是其整體錯(cuò)誤率環(huán)比過(guò)去有明顯下降。經(jīng)過(guò)聽(tīng)云App第三方調(diào)用的分析，再經(jīng)過(guò)研發(fā)優(yōu)化，整體錯(cuò)誤率大幅下降。

 

 

    經(jīng)分析，在南方兩個(gè)區(qū)域城市的用戶體驗(yàn)不理想，且反映出雖其中一個(gè)區(qū)域運(yùn)營(yíng)商WiFi用戶問(wèn)題明顯較多，但平均響應(yīng)時(shí)間表現(xiàn)不很理想，隨后便要進(jìn)行優(yōu)化。

 

 

    有時(shí)候，部分HTML5頁(yè)面中會(huì)存在JS腳本錯(cuò)誤，如果Webview中吞吐率較高的HTML5頁(yè)面存在腳本異常錯(cuò)誤的話便可能會(huì)影響到業(yè)務(wù)，而這些也是通過(guò)聽(tīng)云App監(jiān)測(cè)發(fā)現(xiàn)的。

 

    使用聽(tīng)云Network對(duì)聚美優(yōu)品進(jìn)行監(jiān)控：

 

 

    一般在大促上線前會(huì)使用聽(tīng)云Network進(jìn)行壓力測(cè)試，通過(guò)幾十萬(wàn)注冊(cè)用戶，可控的終端，用腳本錄制回放的方式對(duì)上線前業(yè)務(wù)進(jìn)行現(xiàn)網(wǎng)業(yè)務(wù)模擬測(cè)試，可以模擬在大并發(fā)業(yè)務(wù)下的壓力情況，看到大壓力下全國(guó)用戶的各省、市、運(yùn)營(yíng)商、接入方式的用戶體驗(yàn)，及服務(wù)器的性能波動(dòng)。

 

 

    一般的電商網(wǎng)站首頁(yè)都會(huì)出現(xiàn)由于圖片體積過(guò)大而造成的訪問(wèn)緩慢，有時(shí)候甚至圖片體積超過(guò)了行業(yè)參考值，因此需要隨時(shí)進(jìn)行優(yōu)化。聽(tīng)云Network的監(jiān)測(cè)可以幫助及時(shí)發(fā)現(xiàn)問(wèn)題，在調(diào)整后可以減少頁(yè)面體積，提升用戶體驗(yàn)，節(jié)省寶貴CDN帶寬資源。

    劫持分析，以下劫持發(fā)生的情況均來(lái)自于聽(tīng)云Network和聽(tīng)云App的劫持分析功能

 

    從PC端上看，一般DNS劫持在整體劫持上占到3%左右，而整體劫持在北方發(fā)生的比例較高，內(nèi)容劫持集中發(fā)生在南方。

 

    從客戶端看，DNS劫持較PC端較低，其中主要發(fā)生在北方區(qū)域，且集中在運(yùn)營(yíng)商4G服務(wù)商。

 

 

    通過(guò)聽(tīng)云Network發(fā)現(xiàn)有時(shí)HTML5頁(yè)面會(huì)出現(xiàn)白屏現(xiàn)象，其原因主要集中在HTTPS上，出現(xiàn)了較多的SSL握手時(shí)間較長(zhǎng)，導(dǎo)致頁(yè)面超時(shí)。

 

    問(wèn)題與思考，未來(lái)的監(jiān)控平臺(tái)之路

 

    平臺(tái)建設(shè)之路并非一帆風(fēng)順，在建設(shè)這套CMDB+Zabbix的監(jiān)控平臺(tái)過(guò)程中，聚美優(yōu)品遇到了很多的問(wèn)題，無(wú)論是展示板還是告警策略的設(shè)置，包括建設(shè)CMDB當(dāng)中也遇到了一些困擾的問(wèn)題，崔星表示，這些問(wèn)題可能很有參考價(jià)值。

 

 

    有些監(jiān)控指標(biāo)，例如磁盤(pán)空間，網(wǎng)絡(luò)流量常常因?yàn)橐恍┰�因發(fā)生上下波動(dòng)情況，從而收到大量的報(bào)警，為了防治這種不斷波動(dòng)的情況，可以通過(guò)設(shè)置Zabbix的TRIGGER來(lái)抑制這種情況發(fā)生。
 

 

圖6 報(bào)警抖動(dòng)

 

 

    Zabbix趨勢(shì)數(shù)據(jù)存儲(chǔ)了對(duì)應(yīng)監(jiān)控項(xiàng)目的歷史數(shù)據(jù)在一個(gè)小時(shí)內(nèi)的最大值，最小值，平均值，以及這一小時(shí)內(nèi)采集數(shù)據(jù)的個(gè)數(shù)。如果要保留歷史峰值，避免被平均化，那么在設(shè)置繪圖時(shí)，就應(yīng)該用max而不是avg。
 

 

圖7 數(shù)據(jù)峰值平均化

 

 

    在大型的Zabbix環(huán)境中，遇到的最大挑戰(zhàn)是數(shù)據(jù)庫(kù)。當(dāng)采用最常見(jiàn)的MySQL時(shí)，每天采集的監(jiān)控?cái)?shù)大約是5億條，如果不去管理這些數(shù)據(jù)，繼續(xù)增長(zhǎng)，那么數(shù)據(jù)庫(kù)的性能會(huì)越來(lái)越差，相對(duì)的ZabbixServer的性能也會(huì)隨之下架，這個(gè)怎么樣解決？

 

    第一是硬件設(shè)備，磁盤(pán)盡量采用SSD；隨后對(duì)數(shù)據(jù)庫(kù)參數(shù)調(diào)優(yōu)，同時(shí)對(duì)Zabbix相關(guān)表進(jìn)行表分區(qū)，關(guān)閉Zabbix自帶的housekeepe。

 

    最后MySQL表分區(qū)的操作：
 

 

圖8 MySQL表分區(qū)

 

    可以參考官方提供的分區(qū)方案：https：//www.zabbix.org/wiki/Docs/howto/mysql_partition，把分區(qū)表建立好之后我們可以看到，大概可以承受聚美優(yōu)品現(xiàn)在所實(shí)現(xiàn)的60多萬(wàn)個(gè)指標(biāo)的壓力。
 

 

圖9 60多萬(wàn)個(gè)指標(biāo)的壓力
 

    60多萬(wàn)個(gè)指標(biāo)的壓力也并不是終點(diǎn)，隨著業(yè)務(wù)的不斷擴(kuò)張，即使是現(xiàn)有運(yùn)行良好的監(jiān)控系統(tǒng)平臺(tái)，也會(huì)有瓶頸的一天，技術(shù)也在不斷的發(fā)展，未來(lái)的的監(jiān)控系統(tǒng)建設(shè)之路又將是另一番天地。