案例 | 中移在線:云原生下的監控能力演進

后來血淚史才發現，原來以業務監控和客戶體驗才是我們最終的目標。”

——王漫雪,?技術經理，中移在線服務有限公司

本文整理自王漫雪在2020Zabbix中國峰會的演講，ppt可在網盤獲取:?https://pan.baidu.com/s/193LSRNQGmBbqk9Doj4PEpg? 密碼:ypur

更多演講視頻可關注官方Bilibili賬號主頁（ID：Zabbix中國）。

一 背景-全國集中維護、全球最大

本次演講分五個主題，背景、出路、轉型、沉淀、蛻變。中移在線服務有限公司是中國移動旗下的專業子公司，不管你是給10086打電話還是通過10086的微信公眾號、小程序辦理話費查詢業務，這些系統都是我們公司在進行支持。

我們公司算是傳統的公司，最近也做了很多升級，廣東省的用戶有可能在使用5G手機，同時用了5G套餐的情況下，非常有可能接待你的都是視頻客服，美女小姐姐面對面跟你做服務介紹。隨著我們的服務、業務、運維、形態都在升級，目前面臨的運維挑戰是巨大的。

01- 積極應對挑戰

中國移動有9.1億的用戶，9.1億用戶多不多？我們做個對比，我查了微信的用戶是12億，支付寶的用戶是10億，非常火的抖音的用戶是5億，我們9.1億應該是非常接近一線的互聯網公司了。這么大的用戶量代表著系統線上肯定是一個分布式高并發的系統，它是很復雜的，對于我們的運維挑戰也是很多的。

大家可以看到，現在線上生產環境的容器已經有3萬+了，物理機也有2萬多臺，業務系統也是變化很快的，采用了很多新的技術，比如說微服務、容器，日均上線是120次，這在傳統的運營商里面是非常龐大的數量了。最后就是要求高，很難想象，如果10086電話打不通了，可能這個事就要上新聞了。

二 出路 擁抱開源

01-?擁抱開源

對于一個傳統的運營商，我們怎么選擇自己的出路呢？對于傳統運營商來講，我們可能沒有像BAT一樣非常高精尖的人才，我們可能也不懂系統內核是怎么開發的，想要自己脫離于廠商做一個完全自主化的運維平臺系統，在短時間之內幾乎是很難很難的，那怎么辦呢？我們只能去擁抱開源。

在我接手中移在線的時候，我們的監控系統是一個非常傳統的廠商提供給我們的，當時我們的監控數據指標是每15分鐘采集一次，我壓根看不到監控數據采商長什么樣子，只有故障的時候我收到一條短信告訴我你現在CPU利用率高了，當時我很痛苦，那怎么辦？

新時期的監控需求也擺在這兒了，我們需要跨層，很多很多各種各樣的設備，有新的也有老的，我們還需要跨域，還需要高實時，還需要可持續化，這樣的監控需求擺下來，做了很多的技術調研之后，我們選擇站在Zabbix這個巨人的肩膀上。利用Zabbix的成熟能力，一個月之內快速完成了監控系統的生產上線。以及包括37個監控模板的搭建，3個月之內就覆蓋了總部加31個省份公司100%的技術監控，這個速度是不可想象的，本身Zabbix也是非常成熟的，它可以實現秒級數據采集，從2017年到現在基本上沒有出現重大的故障。

最后跟Grafana做了一個很好的結合，利用它的開源可視化的自定義的看板，給大家輸出來了很多的監控報表。本身Zabbix的代碼寫得非常高效，因為是C語言寫的，本身系統的資源消耗是很低的。

看下我們的建設模式，剛才忘了介紹，我們公司有兩個集中的數據中心，在31個省、市還有31個分公司，為了讓監控能力快速推廣開，我們就采用了總部集中建設、統一管控，分公司標準化接入的建設模式，快速利用Zabbix通用的監控模板，包括自己開發了一些，適配了一些，做了37項能力，總部就負責把監控能力建設，便邊界點的標準化，所有監控數據的上收分析展現與通知，分公司只需要簡單的把監控持續維護下去就可以了。

02- 統一監控平臺

下面來給大家看一些展示，這是所有Zabbix目前覆蓋的公司用到的所有通用中間件，這是我們做的，大家都知道中國移動網絡設備都是集采，所以你會遇到很多很多各家的網絡設備，所以用Zabbix我們也把它統一的搞定了。這是用grafana做的可視化的看板。當時半年的時間我們已經累計了如下的指標，半年時間把2萬主機全部覆蓋了，也累計了200萬個監控項，當時我們看起來覺得這個已經很多的量級了。

所以在200萬監控指標的壓力下，我們也做了一系列Zabbix的系統優化，包括它的數據庫，因為我們當時用的還是老的，3.6版本，所以當時用的是mysql數據庫，強烈建議各位如果你們用的也是老版本的話，希望你們也用純SSD的物理機，這樣不會讓數據庫在一定量級的監控項下成為瓶頸。就是隨著監控量級的增加，我們也遇到了一些問題，這些問題相關解決方案也列在PPT里了，時間原因我就先不細講了。

今年我們也做了Zabbix的雙中心高可用方案，因為我們現在公司的所有核心系統全部都是雙中心高可用的，我們在北方的省份有數據中心，在南方的省份有數據中心，北方中心承擔了15個省份的業務流量，南方中心承擔了15個省份的業務流量，但是因為歷史原因，監控系統剛開始建立在了北方中心里面，Zabbix server大家知道我們采用的是只有一個server存活在北方中心里面，左邊半邊我們做了一些高可用，但是有一天領導把我抓過來問了我一句，他說萬一北方中心掛了怎么辦？

那我們業務是可以實現通過DNS域名解析把北方事故流量快速切換到南方，但是我們突然發現那個時候我們沒監控了，這個是老板不能允許的。后來我們就想了一種方案，能在10分鐘之內幫助我們把這個監控全部切換到南方中心的備節點上，保證我們在所有業務切到南中心的時候，我們還有監控可以看，只是歷史數據看不了了，但是會有新鮮的監控產生，給了我們一個備用的方案。

03- 經驗分享

在這兒總結一下，前期野蠻推廣的經驗，在線當時推廣的時候，因為時間的原因，我們希望能夠快速地把能力覆蓋到31個分公司，所以我們走了一條不太正常的道路，我們是摸著石頭過河。先是需求分析，功能驗證完直接就全網推廣了，隨著監控數量的增加，我們才想起來要做性能監控，包括一些典型問題的處理。最后才做了規范化的制定和整改。

中間我們付出了非常慘痛的代價，我們發現這個加著加著，當前的模板沒有做好規范化的處理，回頭再改的時候會發現之前加的監控找不到了，或者有些監控我想改也不知道怎么改。所以推薦大家，先做需求分析，然后做標準化的規范制定，比如說模板名稱、主機群組、主機名字、動作名字、展板名字，都是需要有一定的關聯性的，最后做一下性能調優，才能去全網推廣，這是一個比較合理的順序。

二?轉型 幾個問題及解決方案

200萬監控指標，出了問題仍不知道？

后來血淚史才發現，原來以業務監控和客戶體驗才是我們最終的目標。”

——王漫雪,?技術經理，中移在線服務有限公司

本文整理自王漫雪在2020Zabbix中國峰會的演講，ppt可在網盤獲取:?https://pan.baidu.com/s/193LSRNQGmBbqk9Doj4PEpg? 密碼:ypur

更多演講視頻可關注官方Bilibili賬號主頁（ID：Zabbix中國）。

一 背景-全國集中維護、全球最大

本次演講分五個主題，背景、出路、轉型、沉淀、蛻變。中移在線服務有限公司是中國移動旗下的專業子公司，不管你是給10086打電話還是通過10086的微信公眾號、小程序辦理話費查詢業務，這些系統都是我們公司在進行支持。

我們公司算是傳統的公司，最近也做了很多升級，廣東省的用戶有可能在使用5G手機，同時用了5G套餐的情況下，非常有可能接待你的都是視頻客服，美女小姐姐面對面跟你做服務介紹。隨著我們的服務、業務、運維、形態都在升級，目前面臨的運維挑戰是巨大的。

01- 積極應對挑戰

中國移動有9.1億的用戶，9.1億用戶多不多？我們做個對比，我查了微信的用戶是12億，支付寶的用戶是10億，非常火的抖音的用戶是5億，我們9.1億應該是非常接近一線的互聯網公司了。這么大的用戶量代表著系統線上肯定是一個分布式高并發的系統，它是很復雜的，對于我們的運維挑戰也是很多的。

大家可以看到，現在線上生產環境的容器已經有3萬+了，物理機也有2萬多臺，業務系統也是變化很快的，采用了很多新的技術，比如說微服務、容器，日均上線是120次，這在傳統的運營商里面是非常龐大的數量了。最后就是要求高，很難想象，如果10086電話打不通了，可能這個事就要上新聞了。

二 出路 擁抱開源

01-?擁抱開源

對于一個傳統的運營商，我們怎么選擇自己的出路呢？對于傳統運營商來講，我們可能沒有像BAT一樣非常高精尖的人才，我們可能也不懂系統內核是怎么開發的，想要自己脫離于廠商做一個完全自主化的運維平臺系統，在短時間之內幾乎是很難很難的，那怎么辦呢？我們只能去擁抱開源。

在我接手中移在線的時候，我們的監控系統是一個非常傳統的廠商提供給我們的，當時我們的監控數據指標是每15分鐘采集一次，我壓根看不到監控數據采商長什么樣子，只有故障的時候我收到一條短信告訴我你現在CPU利用率高了，當時我很痛苦，那怎么辦？

新時期的監控需求也擺在這兒了，我們需要跨層，很多很多各種各樣的設備，有新的也有老的，我們還需要跨域，還需要高實時，還需要可持續化，這樣的監控需求擺下來，做了很多的技術調研之后，我們選擇站在Zabbix這個巨人的肩膀上。利用Zabbix的成熟能力，一個月之內快速完成了監控系統的生產上線。以及包括37個監控模板的搭建，3個月之內就覆蓋了總部加31個省份公司100%的技術監控，這個速度是不可想象的，本身Zabbix也是非常成熟的，它可以實現秒級數據采集，從2017年到現在基本上沒有出現重大的故障。

最后跟Grafana做了一個很好的結合，利用它的開源可視化的自定義的看板，給大家輸出來了很多的監控報表。本身Zabbix的代碼寫得非常高效，因為是C語言寫的，本身系統的資源消耗是很低的。

看下我們的建設模式，剛才忘了介紹，我們公司有兩個集中的數據中心，在31個省、市還有31個分公司，為了讓監控能力快速推廣開，我們就采用了總部集中建設、統一管控，分公司標準化接入的建設模式，快速利用Zabbix通用的監控模板，包括自己開發了一些，適配了一些，做了37項能力，總部就負責把監控能力建設，便邊界點的標準化，所有監控數據的上收分析展現與通知，分公司只需要簡單的把監控持續維護下去就可以了。

02- 統一監控平臺

下面來給大家看一些展示，這是所有Zabbix目前覆蓋的公司用到的所有通用中間件，這是我們做的，大家都知道中國移動網絡設備都是集采，所以你會遇到很多很多各家的網絡設備，所以用Zabbix我們也把它統一的搞定了。這是用grafana做的可視化的看板。當時半年的時間我們已經累計了如下的指標，半年時間把2萬主機全部覆蓋了，也累計了200萬個監控項，當時我們看起來覺得這個已經很多的量級了。

所以在200萬監控指標的壓力下，我們也做了一系列Zabbix的系統優化，包括它的數據庫，因為我們當時用的還是老的，3.6版本，所以當時用的是mysql數據庫，強烈建議各位如果你們用的也是老版本的話，希望你們也用純SSD的物理機，這樣不會讓數據庫在一定量級的監控項下成為瓶頸。就是隨著監控量級的增加，我們也遇到了一些問題，這些問題相關解決方案也列在PPT里了，時間原因我就先不細講了。

今年我們也做了Zabbix的雙中心高可用方案，因為我們現在公司的所有核心系統全部都是雙中心高可用的，我們在北方的省份有數據中心，在南方的省份有數據中心，北方中心承擔了15個省份的業務流量，南方中心承擔了15個省份的業務流量，但是因為歷史原因，監控系統剛開始建立在了北方中心里面，Zabbix server大家知道我們采用的是只有一個server存活在北方中心里面，左邊半邊我們做了一些高可用，但是有一天領導把我抓過來問了我一句，他說萬一北方中心掛了怎么辦？

那我們業務是可以實現通過DNS域名解析把北方事故流量快速切換到南方，但是我們突然發現那個時候我們沒監控了，這個是老板不能允許的。后來我們就想了一種方案，能在10分鐘之內幫助我們把這個監控全部切換到南方中心的備節點上，保證我們在所有業務切到南中心的時候，我們還有監控可以看，只是歷史數據看不了了，但是會有新鮮的監控產生，給了我們一個備用的方案。

03- 經驗分享

在這兒總結一下，前期野蠻推廣的經驗，在線當時推廣的時候，因為時間的原因，我們希望能夠快速地把能力覆蓋到31個分公司，所以我們走了一條不太正常的道路，我們是摸著石頭過河。先是需求分析，功能驗證完直接就全網推廣了，隨著監控數量的增加，我們才想起來要做性能監控，包括一些典型問題的處理。最后才做了規范化的制定和整改。

中間我們付出了非常慘痛的代價，我們發現這個加著加著，當前的模板沒有做好規范化的處理，回頭再改的時候會發現之前加的監控找不到了，或者有些監控我想改也不知道怎么改。所以推薦大家，先做需求分析，然后做標準化的規范制定，比如說模板名稱、主機群組、主機名字、動作名字、展板名字，都是需要有一定的關聯性的，最后做一下性能調優，才能去全網推廣，這是一個比較合理的順序。

二?轉型 幾個問題及解決方案

200萬監控指標，出了問題仍不知道？

海量日志是否有利用價值？

容器上的監控怎么做？

01- 200萬監控指標，出了問題仍不知道？

到了轉型期，我們依然面對了很多問題，下面大家來看第一個問題，累計了200萬指標還很得意的時候，我們的業務系統有一次掛了，掛完之后老板把我們叫到面前，漫雪，為什么掛了我沒有收到短信，你都200萬指標為什么沒有告警，這個時候我才幡然醒悟，我那200萬指標做的都是基礎監控的一些監控指標的覆蓋，業務監控系統掛了不掛了我還是不知道。

后來血淚史才發現，原來以業務監控和客戶體驗才是我們最終的目標。所以我們要把從基礎設施管理到應用系統管理，一直上升到后面業務質量管理與客戶體驗管理。這里面我做了很多事情，第一個是加了應用性能的監控，也就是傳統業界所說的APM，另外也把核心系統全部梳理了一遍，按照谷歌SRE的五項黃金指標，要求了每個業務系統都必須更我們梳理一些核心的KPI，方便我們對業務系統的實時運行狀態來做監控。

這時候又有一個問題了，老板說什么時候是個頭呢，你怎么能告訴你的老板，我現在已經能把加的監控全部加完了。這個時候我們又做了一個事情，就是梳理了一下云化架構下我們認為的監控分層，以及每一層都應該涉及到的監控指標，就是這個金字塔型結構。這個時候我們就會發現，其實業務監控能發現70%的問題，基礎監控可能只能發現30%的問題，所以會把更多的經歷投入到了在業務監控方面的添加。

02- 海量日志是否有利用價值？

面臨到第二個問題，我們剛才講到了線上的業務監控系統大概有200多個，全網的主機大概有3萬臺，不管是業務系統產生的日志也好，網絡設備產生的日志也好，海量日志是不是有用？為此我們發現了，其實對于亞健康狀態，異常日志要比系統故障出現得更早一些。所以本著這個，我們能更早地發現故障，我們去做了一套統一的日志平臺，通過這種有代理的模式和一些無代理的模式，把所有跨廠商的設備日志，包括業務日志全部集中到了一個日志平臺里面，做統一的查詢處理和告警分析。

這是我們的統一日志平臺，采集的方式有很多種，包括HTDP、TCP、UDP、文件監聽、SYSLOG的。另外，我們也做跨網傳輸，剛才講了我們有31個分公司，有31個邊緣節點，所以要把分公司的日志全部傳到本部的平臺上面來，也用了Flink實時大數據的計算能力，把日志匯聚在一起，最后也實現了，通過全局的唯一追蹤ID，實現了業務系統日志里面的上下文的查詢，以及全鏈路的調用鏈的分析。

這個時候我們已經清楚地具備了業務系統，比如說A調B，B調C，C掛了影響AB，或者是用戶說很慢、很卡頓，但是具體不知道慢在哪一個業務系統的調用鏈上，這個時候通過日志平臺做到了這個層次的監控。來看一下日志平臺的相關數據，我們每天要處理600億行的日志，目前整個日志平臺的集群節點有400多個。

03- 容器上的監控怎么做？

接著就是在2019年底，公司的底層技術做了升級，把我們也折騰了不輕，從之前以openstack技術為主的虛擬化云計算升級成了容器，在容器上的監控應該怎么做成為了首要思考的問題。這個時候因為我們公司底層的容器云量是基于k8s二次開發得來的，所以當時選用了跟k8s相生的prometheus。

當時在容器上面做了包括容器主機的監控、云資源使用近況的監控，容器狀態的監控，包括一些集群事件之間的監控，還總結了一些包括容器上跑的業務的監控，包括入口返還量的監控，接口的調用監控，包括核心日志的異常關鍵字監控，dubbo線程池狀態的監控等等。

04-自主可控的監控告警體系建設

最后總結一下，這個時候通過大家前面聽我的講述，底層用了很多不同的開源平臺，去為我們采集各種各樣適合做的監控數據采集，所以我們就發現現在該要整合了，怎么能打造一套統一的監控平臺呢？底層、通過日志平臺、prometheus、Zabbix，APM、包括一些傳統的專業網管設備，把它統一地劃分成了數據采集的平臺，上面把采集上來的監控數據，不管是統一送到ES里面，把它分為好多份，不管是做實時處理也好，做離線分析也好，還跟資源管理的數據，以及智能化的規則關聯在一起，做了很多上層的應用。

這些應用就貫穿到了整個故障處理的場景，包括監控系統，做了這種智能故障發現，故障定級，告警系統要做智能通知，流程要去派單，完成告警的閉環管理。接著我們要做大數據的分析與決策，最后通過自動化平臺來完成故障自愈。

四 沉淀-讓監控更多可能

01- 自動化提速

第一，剛才做了這么多監控，我們怎么能保證監控服務更及時？31個分公司，每人一天給我提一個工單，我一天就31個工單，所以我在很長一段時間，在沒有做自動化之前，我被投訴最多的事情就是漫雪你的監控需求支撐不到位，我的分公司想要加個監控還要等上兩天，這不行，監控不等人。怎么辦，當時已經雇了15個廠商，每天專門做工單，這個代價成本是很高的，后來我們就想辦法，發現其實很多監控能力，像Zabbix，通過模板的標準化，通過ZabbixAPI，我們其實是可以實現自動化的增刪改，所以現在通過一系列標準化梳理，已經做了二次開發，基于Zabbix和prometheus，我們做了這一整套的監控自助的工具，能實現覆蓋目前85%的監控需求，把這套工具放上去，把權限給你，把監控的列表也給你，你就可以實現自助化的添加了，只需要做簡單的培訓，只需要在頁面上點點點就行了，不需要去了解Zabbix原理是什么，什么是prometheus，我把它透明化了。

但是這個時候就帶來了下一個問題，服務自動化的底線在哪里？因為我把這些服務都放出去之后，我們是屬于運維團隊的，運維是為公司的生命線做保障的，但是我們把有些自助服務放給了研發同學，這個時候不是黑他們。放給研發同學之后，研發同學就會覺得每天收的短信太多了，我們原本可能把CPU大于75，然后我就告警了，后來發現大于75也不一定每回都有事，那要不然我改改吧，我改成90，過兩天我可能就改成95了，因為我總覺得它會沒問題。這時候就出現我把自動化的服務權限放給所有人之后，我很難保證所有人的思想意識能高度統一，所有人都有責任心。有可能今天為了少收兩條短信就把這個監控給我刪掉了。這個時候出現故障了，老板不會去找他，老板只會找你，你這個監控平臺怎么又沒告警？

所以面臨這個問題，我們在用戶便利性和監控的管理上面做了很長時間的思考和battle，最后劃了17種網源監控類型，定了一些不可更改的生命線，這個活動我們叫得很通俗，就叫“掛了我知道”。這些監控是你不能改的，是我們默認添加的。比如說你今天有一個業務系統上線，你用監控自助加了，你添加的過程當中，這底下不可更改的生命線是我們默認給你加上去的，對你來說是透明的，你也不能改，因為我們要知道生產所有的系統，掛了情況下運維團隊是要第一時間知道的。

02- 數據化賦能

接著就是數據化的賦能，剛才大家看到了整個監控平臺上面是有一層dpas層的，把很多的自助化的監控工具，把數據抽上來之后做什么用呢？可以做很多的報表分析，可以提供非實時性的業務健康性的周報分析之類的，另外還可以豐富很多的指標，最后給大家重點推薦的還是應用的擴展，做了很多故障快速定位、根因分析、故障自愈和容量管理。

下面來看第一個就是根因分析，現在很多業界都在講AIOPS，很多廠商來跟我們說通過智能化的算法，可以給你做到根因定位，但事實上來說，短時間之內智能化算法能起到什么作用，完全取決于數據的質量以及數據的累計。在這些東西都沒有的時候怎么辦，我們打造了一套法典——兩套拓撲。

第一套拓撲，就是我們把監控告警數據跟資源管理，CMDB里面的數據深層結合起來，形成了一個縱向的拓撲，它能告訴你，我的業務系統現在都用了哪些中間件，用了哪個數據庫，用了哪個MQ，這個業務系統都部署在哪些基礎設施上面，我的網絡設備掛了，到底能影響哪些業務系統，這是一層縱向拓撲。

接著就是一項橫向拓撲，這個講到剛才利用日平臺，整個跟企業消息總線關聯在一起，打造了一層橫向拓撲，它用來干嗎？它告訴你業務系統之間調用關系，業務A掛了，能影響哪些業務系統，當橫向拓撲和縱向拓撲聯合在一起，你就能實現最終的四看一報了，這個時候我就能拍著胸脯跟老板講，業務系統哪掛了，至少我知道。

接著就是故障自愈，這個是把監控數據提取出來之后，我們跟自動化運維平臺結合在一起。至少實現一些簡單場景，固定場景下的故障自愈。比如說自動擴容、自動重啟以及自動的接口關閉，這個地方要講一下，如果你想實現自動的接口關閉，必須得做到業務系統的配合，不能業務系統不配合，你就把接口關了，那業務系統有可能會掛。

接著就是通俗意義上的容量管理，容量管理還是很重要的，大家都在講開源、節流、降本、增效。怎么降本？其實都要看監控采上來的數據做精細化的處理，可能要給你的運維團隊或者是業務團隊定期發一些報表，告訴他哪些主機資源利用率用的實在是很低，然后你可以退回去，或者提高一下資源利用率。

來看一下現在的數字，就是一系列監控平臺在線上跑了三年之后，全網有3.4萬主機，我有2606監控項，78萬觸發器，每天處理600億的日志，給大概將近1000個用戶提供一系列的服務。

五? 蛻變- AIOPS在監控告警的應用

最后，忍不住要嘗試一把AIOPS，畢竟最近這么火，我們覺得很多經驗累計起來，底下要講的應用是我們覺得最初級、最入門，大家普遍都能去嘗試的一個東西。首先還是問題，我寫這個PPT的思路就是遇見問題解決問題，然后來推動平臺去往前技術的演進。

01- 閾值正確設定

這個問題就是領導要求，發生故障了必須得監控系統第一時間知道，你得有報警短信發出來，這是這個系統存在的意義和價值。我們的運維人員就會說一天處理2000多條短信，我根本看不過來，我壓根就不想看。那在多和少之間，我們怎么去權衡這個問題，然后我們做了一系列的數據分析，然后就發現了在告警這個層面，可能正常告警缺少的是關聯和壓縮，誤報漏報中間有很多問題都是基于閾值設置的不太合理，也就是說沒有人，新業務系統上線，可能開發人員自己就沒有辦法很精準地告訴你，我什么情況下這個業務系統核心KPI指標是不正常的，這個時候怎么辦？

我們研究了一下閾值設定有三個層面，包括規則設定，大家拍腦子，CPO利用率大于95%普遍都覺得有問題，到通過大數據分析，我看了一下歷史的三個月，這個系統核心KPI指標跑在哪兒，最后就是智能化的閾值預定，這個業界普遍叫做指標的異常檢測。

02- AI預測擬合曲線

我們是通過這種首先把監控單個指標的數據做歷史數據的分析，因為周期性的數據是比較好做智能預測的，非周期性的要做一定的數據清洗，接著做一些毛刺檢測，最后用LSTM一些數據分析的算法去做異常判定，它能智能地幫你找到系統現在到底異常還是不異常。

這是一個圖的舉例子，比如說藍的指標是預測指標，綠色指標是實時指標、現實指標，黃的現在就是異常判定的方差線，三個線放在一起，超過黃線的，或者是高于黃線、低于黃線都是異常點，這個就可以充分證明你的系統現在是有問題的。

03- 智能化運維

最后，為什么講這個事？主要是覺得智能化運維離傳統的運營商和傳統的其他廠商來講并不是那么遙遠，本身具備了很多數據，現在業界有很多成熟的算法，基于結構化的數據，需要的計算資源是非常少的，不是像語音、圖像需要服務器，虛擬機數量少的話虛擬機都可以起步的。

白皮書應該很多人都見過，AIOPS實施的白皮書里面有三個常見的應用場景，在這些應用場景里面紅色的是我們現在正在嘗試并且取得了一定成果的，異常檢測、根因分析以及智能客服。這是我們正在做的，比如說日志的異常檢測，告訴你壓縮關聯、根因分析，以及一些容量管理上面的缺失預測之類的。

謝謝大家！（ppt可在網盤獲取:? https://pan.baidu.com/s/193LSRNQGmBbqk9Doj4PEpg? 密碼:ypur）

Zabbix

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。