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

 

 

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

 

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

 

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

 

    2、不利于自動化：指標更新很復雜，配置一個指標，要更改指標項目，監(jiān)控項目，這時候需要通過工具批量執(zhí)行

 

    3、告警策略的維護：變更代價太大

 

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

 

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

 

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

 

    強大的數據采集

 

    高效的告警策略

 

    個性化的告警設置

 

    多維度的數據展示

 

    可水平擴展

 

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

 

 

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

 

圖1 監(jiān)控平臺的體系架構圖

 

    從圖中，我們可以看到有很多亮點：

 

    數據采集：agent自動發(fā)現(xiàn)，主動推送模式

 

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

 

    告警策略人性化：遞延報警，報警暫停，按時段發(fā)送不同類型告警

 

    DashbOArd：多維度數據展示，Top指標對比等功能

 

    自動管理：自動清除下限機器，自動更新項目類型

 

 

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

 

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

 

    支持維護周期設置：想告警幾天就設置告警幾天，如果不想監(jiān)控，可以永久關閉；如果某臺機器凌晨五點不想告警的話，可以在這段時間進行關閉。

 

    自定義告警類型：可以通過短信或者郵件告知。

 

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

 

    告警分析：通過一些定義很嚴重的告警，分很多等級，不同的等級可以發(fā)送給運維人員。

 

    告警遞延：第一次告警是運維人員，如果運維人員半個小時之后沒有處理，告警信息會上報給開發(fā)人員或者是部門主管。
 

 

   圖2 支持告警恢復通知

 

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

 

 

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

 

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

 

圖3 Dashboard
 

    用戶自定義Dashboard：開發(fā)人員和運維人員可以根據自己的習慣進行使用

 

    項目層級展示：當項目很多時，可以歸類已不同層級展示

 

    指標對比分析：在遇到一些類似大促這樣的情況時，假設有一百臺機器，通過指標對比可以知道誰的網卡最高，例如圖中我們看到藍色波動，是不是這個時間段出現(xiàn)了一些異常，是配置錯了？還是機器本身有問題，可以通過對比指標找出原因。
 

 

圖4 Top指標實時統(tǒng)計

 

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

 

 

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

 

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

 

 

    通過聽云App對崩潰進行分析，進行不斷地bug修復，聚美優(yōu)品每迭代一個新的版本崩潰率都會有明顯的下降。

 

    劫持分析
 

 

圖5 劫持分析

 

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

 

    1、通過使用聽云App的劫持分析在全國范圍內劫持比例在2個月下降50%。

 

    2、聚美會派專人每天將聽云統(tǒng)計的崩潰原始數據導入平臺，再配合安排相關測試解決響應Bug，跟蹤Bug處理進度，半年來崩潰比例下降明顯，投訴率大幅下降，用戶粘度提升顯著。

 

    3、聽云App提供的行業(yè)數據對指導優(yōu)化很有幫助，隨著直播業(yè)務的展開，對標行業(yè)趨勢很有必要。

 

 

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

 

 

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

 

 

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

 

 

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

 

    使用聽云Network對聚美優(yōu)品進行監(jiān)控：

 

 

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

 

 

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

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

 

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

 

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

 

 

    通過聽云Network發(fā)現(xiàn)有時HTML5頁面會出現(xiàn)白屏現(xiàn)象，其原因主要集中在HTTPS上，出現(xiàn)了較多的SSL握手時間較長，導致頁面超時。

 

    問題與思考，未來的監(jiān)控平臺之路

 

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

 

 

    有些監(jiān)控指標，例如磁盤空間，網絡流量常常因為一些原因發(fā)生上下波動情況，從而收到大量的報警，為了防治這種不斷波動的情況，可以通過設置Zabbix的TRIGGER來抑制這種情況發(fā)生。
 

 

圖6 報警抖動

 

 

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

 

圖7 數據峰值平均化

 

 

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

 

    第一是硬件設備，磁盤盡量采用SSD；隨后對數據庫參數調優(yōu)，同時對Zabbix相關表進行表分區(qū)，關閉Zabbix自帶的housekeepe。

 

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

 

圖8 MySQL表分區(qū)

 

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

 

圖9 60多萬個指標的壓力
 

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