2020年全球運(yùn)維大會(huì)-全球最大呼叫平臺(tái)監(jiān)控實(shí)踐課件

全球最大呼叫平臺(tái)監(jiān)控實(shí)踐之路

全球最大呼叫平臺(tái)監(jiān)控實(shí)踐之路1目錄背景-全國集中維護(hù)、全球最大1出路-選擇開源2轉(zhuǎn)型-幾個(gè)問題3蛻變-AIOPS在監(jiān)控報(bào)警方面的嘗試4

目錄背景-全國集中維護(hù)、全球最大1出路-選擇開源2轉(zhuǎn)型-幾個(gè)2中移在線公司移動(dòng)全網(wǎng)集中服務(wù)提供者移動(dòng)全網(wǎng)業(yè)務(wù)后臺(tái)集中處理者移動(dòng)全網(wǎng)渠道運(yùn)營集中支撐者201431省呼叫業(yè)務(wù)完成劃轉(zhuǎn)奠定全網(wǎng)集中化運(yùn)營基礎(chǔ)2016實(shí)現(xiàn)盈利業(yè)務(wù)發(fā)展和改革創(chuàng)新初見成效全集團(tuán)首批入選國資委國企改革“雙百行動(dòng)”三家公司之一2018201710月注冊成立全集團(tuán)集中化、專業(yè)化運(yùn)營試驗(yàn)田發(fā)展歷程

中移在線公司移動(dòng)全網(wǎng)集中服務(wù)提供者移動(dòng)全網(wǎng)業(yè)務(wù)后臺(tái)集中處理3傳統(tǒng)呼叫中心傳統(tǒng)呼叫中心是基于PBX、專用硬件排隊(duì)機(jī)、硬件語音板卡等專用設(shè)備組成的客服系統(tǒng)。軟硬一體，不夠靈活建設(shè)成本高、周期長、維護(hù)升級困難無法滿足多渠道多媒體互聯(lián)網(wǎng)相關(guān)增值業(yè)務(wù)的融合無法實(shí)現(xiàn)多客服中心坐席跨網(wǎng)協(xié)同無法快速響應(yīng)業(yè)務(wù)需求缺點(diǎn)排隊(duì)機(jī)CTIIVR應(yīng)用PSTN/PLMNPBX坐席坐席

傳統(tǒng)呼叫中心傳統(tǒng)呼叫中心是基于PBX、專用硬件排隊(duì)機(jī)、硬件語4新形態(tài)呼叫中心語音坐席視頻坐席互聯(lián)網(wǎng)坐席熱線互聯(lián)網(wǎng)新形態(tài)下的呼叫中心質(zhì)量管控大數(shù)據(jù)平臺(tái)支持客戶全渠道交互智能質(zhì)檢智能導(dǎo)航智能應(yīng)答轉(zhuǎn)人工智能知識庫坐席助手語音客服視頻客服在線客服智能IVR智能運(yùn)營運(yùn)營管理呼叫平臺(tái)統(tǒng)一排隊(duì)統(tǒng)一路由統(tǒng)一監(jiān)控純軟件：全媒體CTI、IVR、互聯(lián)網(wǎng)接入網(wǎng)關(guān)、軟交換、中繼網(wǎng)關(guān)、媒體加速服務(wù)、用戶終端富媒體：支持傳統(tǒng)語音、文本、圖片、視頻、短語音、微信、微博智能化：與人工智能（AI）、大數(shù)據(jù)技術(shù)結(jié)合，應(yīng)用于IVR、機(jī)器人應(yīng)答、質(zhì)檢、外呼等集中化：接續(xù)、CRM、分析、質(zhì)檢、話務(wù)監(jiān)控等集中化特征

新形態(tài)呼叫中心語音坐席視頻坐席互聯(lián)網(wǎng)坐席熱線互聯(lián)網(wǎng)新形5在線公司:

全球最大呼叫中心河南江蘇北京我們面臨的運(yùn)維挑戰(zhàn)多難高用戶多,

IT規(guī)模接近一線互聯(lián)網(wǎng)企業(yè)9億用戶,

超1億微信粉絲，月服務(wù)超億次，微博矩陣粉絲3038萬（居行業(yè)首位），10086APP超五千萬用戶量20000+服務(wù)器50000+Tomcat業(yè)務(wù)變化快，運(yùn)維環(huán)境復(fù)雜支撐全國營銷活動(dòng)，總部/分公司/省公司多級協(xié)同日均上線

17

次，日處理

206

例工單技術(shù)新：微服務(wù)/云計(jì)算/容器

…要求高，提供電信級服務(wù)99.99%

的可靠性15秒接通要求7*24

小時(shí)保障

在線公司:全球最大呼叫中心河南江蘇北京我們面臨的運(yùn)維挑戰(zhàn)多6轉(zhuǎn)變運(yùn)維思路，適應(yīng)新的時(shí)代挑戰(zhàn)為了支持業(yè)務(wù)快速上線和高效運(yùn)維。在線公司監(jiān)控系統(tǒng)需具備敏捷、集中、自動(dòng)、智能的關(guān)鍵能力。自動(dòng)敏捷之前能力建設(shè)智能現(xiàn)在監(jiān)控能力周粒度提供監(jiān)控能力分鐘級提供按專業(yè)劃分的“煙囪式監(jiān)控”混合集中化監(jiān)控手工添加基于策略的自動(dòng)化閉環(huán)依賴專家經(jīng)驗(yàn)基于AI和大數(shù)據(jù)的自動(dòng)識別集中

轉(zhuǎn)變運(yùn)維思路，適應(yīng)新的時(shí)代挑戰(zhàn)為了支持業(yè)務(wù)快速上線和高效運(yùn)維7目錄1234背景-全國集中維護(hù)、全球最大出路-選擇開源轉(zhuǎn)型-幾個(gè)問題蛻變-AIOPS在監(jiān)控報(bào)警方面的嘗試

目錄1234背景-全國集中維護(hù)、全球最大出路-選擇開源轉(zhuǎn)型-8統(tǒng)一監(jiān)控平臺(tái)：開源工具+二次開發(fā)，自主核心可控監(jiān)控管理Grafana統(tǒng)一門戶ITSM運(yùn)維平臺(tái)自動(dòng)化平臺(tái)CMDB統(tǒng)一告警平臺(tái)統(tǒng)一事件分析告警告警接口性能看板告警事件管理短信郵件工單信息故障定位或修復(fù)場景業(yè)務(wù)看板根因分析業(yè)務(wù)建模業(yè)務(wù)模型和配置數(shù)據(jù)被管環(huán)境Java

App.NET

AppPHP,Python,

NodeJS應(yīng)用系統(tǒng)客服系統(tǒng)監(jiān)控（I2000）應(yīng)用性能監(jiān)控（APM）告警信息場景執(zhí)行調(diào)用性能看板業(yè)務(wù)看板業(yè)務(wù)數(shù)據(jù)PrometheusmetricElasticSearch數(shù)據(jù)庫數(shù)據(jù)庫監(jiān)控（Prometheus）基礎(chǔ)架構(gòu)監(jiān)控（Zabbix）CTI/UAP系統(tǒng)服務(wù)器、網(wǎng)絡(luò)、存儲(chǔ)、虛擬化環(huán)境等告警看板Kafka實(shí)時(shí)融合監(jiān)控：引入業(yè)界開源工具，進(jìn)行二次開發(fā)與封裝，形成核心自主可控、穩(wěn)定高效、海量秒級的監(jiān)控能力?？缬?跨廠商/跨層的IT/CT實(shí)時(shí)融合監(jiān)控。有豐富的管理對象。多樣靈活的數(shù)據(jù)展現(xiàn)形式，可以靈活配置，適應(yīng)不同場景，快速定制。監(jiān)控?cái)?shù)據(jù)

統(tǒng)一監(jiān)控平臺(tái)：開源工具+二次開發(fā)，自主核心可控監(jiān)控管理Gra9統(tǒng)一監(jiān)控平臺(tái)：集中建設(shè)、統(tǒng)一管控、邊緣節(jié)點(diǎn)標(biāo)準(zhǔn)化為了更快速的建立監(jiān)控能力、更全面的管控系統(tǒng)質(zhì)量，在線服務(wù)公司統(tǒng)一監(jiān)控平臺(tái)采用了總部集中建設(shè)、統(tǒng)一管控，分公司標(biāo)準(zhǔn)化接入的建設(shè)模式。全網(wǎng)集中：總部負(fù)責(zé)監(jiān)控能力建設(shè)、邊緣節(jié)點(diǎn)的標(biāo)準(zhǔn)化，所有監(jiān)控?cái)?shù)據(jù)的上收、分析、展現(xiàn)與通知。分公司提供資源，遵照標(biāo)準(zhǔn)化、封裝后的監(jiān)控模板進(jìn)行監(jiān)控資源的維護(hù)與管理。

統(tǒng)一監(jiān)控平臺(tái)：集中建設(shè)、統(tǒng)一管控、邊緣節(jié)點(diǎn)標(biāo)準(zhǔn)化為了更快速的10一些小總結(jié)：半年時(shí)間2萬200

萬90

萬30

萬主機(jī)監(jiān)控項(xiàng)觸發(fā)器報(bào)警84400+5451.3KProxyDashBoard用戶數(shù)動(dòng)作

一些小總結(jié)：半年時(shí)間2萬200萬90萬30萬主機(jī)監(jiān)控11一些小總結(jié)：廣泛、豐富、多樣、靈活

一些小總結(jié)：廣泛、豐富、多樣、靈活12網(wǎng)絡(luò)設(shè)備類型與廠家存活/丟包/時(shí)延CPU/內(nèi)存占用率snmp狀態(tài)溫度端口狀態(tài)出/入口帶寬利用率出/入口丟、錯(cuò)包接口類型設(shè)備狀態(tài) 網(wǎng)卡狀態(tài) 設(shè)備信息端口描述軟件版本系統(tǒng)名稱光功率光模塊接收功率網(wǎng)絡(luò)協(xié)議光模塊發(fā)送 BGP對等體功率 連接狀態(tài)ospf鄰居狀態(tài)vrrp虛擬路由狀態(tài)網(wǎng)絡(luò)監(jiān)控指標(biāo)SNMP一些小總結(jié)：廣泛、豐富、多樣、靈活

網(wǎng)絡(luò)設(shè)備類型與廠家存活/丟包/時(shí)延CPU/內(nèi)存占用率sn13一些小總結(jié)：廣泛、豐富、多樣、靈活看板可靈活制定，分鐘級完成配置。圖表多樣化展現(xiàn)：折線圖、柱狀圖、餅圖、區(qū)域圖、拓?fù)鋱D等。

一些小總結(jié)：廣泛、豐富、多樣、靈活看板可靈活制定，分鐘級完成14主機(jī)參數(shù)內(nèi)核參數(shù)TCP協(xié)議棧參數(shù)信號量/IO（Zabbix啟動(dòng)失敗不釋放信號集）數(shù)據(jù)庫CPU/內(nèi)存/IO連接（最大連接數(shù)、超時(shí)時(shí)長）數(shù)據(jù)一致性強(qiáng)烈建議采用數(shù)據(jù)庫SSD硬盤WEBNginx參數(shù)Php參數(shù)php.ini：max_input_vars（影響模板應(yīng)用大批量主機(jī)失敗）Zabbix視具體需求配置啟動(dòng)模塊和進(jìn)程數(shù)禁用自動(dòng)發(fā)現(xiàn)，采用腳本調(diào)用api實(shí)現(xiàn)禁用housekeeper，啟用數(shù)據(jù)庫表分區(qū)禁用server直連agent配置參數(shù)優(yōu)化defines.inc.php：QUEUE_DETAIL_ITEM_COUNT（定義監(jiān)控項(xiàng)隊(duì)列檢索限制，影響消息隊(duì)列積壓顯示）一些小總結(jié)：zabbix系統(tǒng)優(yōu)化

主機(jī)參數(shù)數(shù)據(jù)庫WEBZabbix一些小總結(jié)：zabbix系統(tǒng)15一些小總結(jié)：zabbix系統(tǒng)優(yōu)化二、Preprocessing

manager

負(fù)荷長期為100%三、Zabbix

server主機(jī)反復(fù)重啟，卻無法啟動(dòng)成功問題現(xiàn)象與影響一、大量消息隊(duì)列積壓（超過20萬），且呈現(xiàn)雪崩效應(yīng)問題定位與解決方案一、zabbix官網(wǎng)對于pre-process耗盡的說明：二、解決方案：1、在zabbix

server所在主機(jī)再單獨(dú)部署一個(gè)proxy節(jié)點(diǎn)。2、將之前由zabbix

server直接監(jiān)控的所有proxy所在主機(jī)的agent節(jié)點(diǎn)，全部轉(zhuǎn)到新增proxy管理。3、降低server的pollers、java

pollers、pingers、trappers等進(jìn)程數(shù)配置。4、增加zabbix

server的自監(jiān)控項(xiàng)配置項(xiàng)及告警（

Pre-process進(jìn)程占用率及zabbix_server.log的異常關(guān)鍵字告警）。

一些小總結(jié)：zabbix系統(tǒng)優(yōu)化二、Preprocessin16Zabbix配置的同步機(jī)制Zabbix的配置表比較多，大容量局點(diǎn)關(guān)聯(lián)查詢sql耗時(shí)很長如數(shù)據(jù)庫控制sql執(zhí)行時(shí)間的max_execution_time配置不合理，會(huì)導(dǎo)致無法將相應(yīng)配置表數(shù)據(jù)同步到zabbix

server以及proxy的cache，從而導(dǎo)致出現(xiàn)大量監(jiān)控項(xiàng)無法正常采集及消息隊(duì)列積壓現(xiàn)象。以下為zabbix_server.log相應(yīng)日志：數(shù)據(jù)庫sql執(zhí)行超時(shí)配置建議根據(jù)現(xiàn)網(wǎng)的數(shù)據(jù)庫IO處理性能以及局點(diǎn)規(guī)模合理配置數(shù)據(jù)庫超時(shí)相關(guān)參數(shù)，將max_execution_time設(shè)置為超過目前zabbix

server同步配置sql執(zhí)行時(shí)長的2倍以上，并定期檢查zabbix_server.log日志的相應(yīng)執(zhí)行時(shí)長，或者增加自監(jiān)控告警。一些小總結(jié)：zabbix系統(tǒng)優(yōu)化

Zabbix配置的同步機(jī)制Zabbix的配置表比較多，大容量17目錄1234背景-全國集中維護(hù)、全球最大出路-選擇開源轉(zhuǎn)型-幾個(gè)問題蛻變-AIOPS在監(jiān)控告警方面的嘗試

目錄1234背景-全國集中維護(hù)、全球最大出路-選擇開源轉(zhuǎn)型-18問題一：200w監(jiān)控指標(biāo)，業(yè)務(wù)出了問題仍然不知道治理范圍應(yīng)用系統(tǒng)管理業(yè)務(wù)質(zhì)量管理客戶體驗(yàn)管理能力擴(kuò)展基礎(chǔ)設(shè)施管理基礎(chǔ)設(shè)施性能管理(PM)基礎(chǔ)設(shè)施故障管理(FM)用戶問題管理用戶感知管理業(yè)務(wù)問題管理業(yè)務(wù)質(zhì)量管理以業(yè)務(wù)質(zhì)量和客戶體驗(yàn)為核心，以可管控、可視化、可度量為目標(biāo)。全網(wǎng)集中建設(shè)、集中管控、邊緣節(jié)點(diǎn)標(biāo)準(zhǔn)化接入。軟件監(jiān)控+硬件監(jiān)控一網(wǎng)打盡，運(yùn)維數(shù)據(jù)統(tǒng)一、融合、流動(dòng)，建立多層次度量體系。以用戶體驗(yàn)出發(fā)，建立端到端全鏈路監(jiān)控，告警+投訴預(yù)警+客服聯(lián)動(dòng)形成完整閉環(huán)管理。運(yùn)維保障應(yīng)用性能管理(PM)應(yīng)用故障管理(FM)流程及自動(dòng)化管理

問題一：200w監(jiān)控指標(biāo)，業(yè)務(wù)出了問題仍然不知道治理范圍應(yīng)19業(yè)務(wù)及應(yīng)用質(zhì)量可感知，是監(jiān)控的核心ServerOSDBJVMMQWEB面向基礎(chǔ)架構(gòu)的監(jiān)控只能發(fā)現(xiàn)約30%的問題從用戶體驗(yàn)出發(fā)面向應(yīng)用的監(jiān)控能發(fā)現(xiàn)約70%的問題最終用戶體驗(yàn)應(yīng)用程序基礎(chǔ)架構(gòu)梳理業(yè)務(wù)系統(tǒng)核心功能模塊梳理功能模塊的核心監(jiān)控指標(biāo)評審監(jiān)控指標(biāo)的提取方式及有效性監(jiān)控看板制作在強(qiáng)化基礎(chǔ)設(shè)置監(jiān)控的基礎(chǔ)上，補(bǔ)充應(yīng)用性能監(jiān)控和業(yè)務(wù)質(zhì)量監(jiān)控能力，保障業(yè)務(wù)的穩(wěn)定性和客戶感知。應(yīng)用性能監(jiān)控 業(yè)務(wù)質(zhì)量監(jiān)控參考Google

SRE五項(xiàng)黃金指標(biāo)1：速率：請求速率，請每秒請求數(shù)量。2：錯(cuò)誤：

錯(cuò)誤率，即每秒錯(cuò)誤數(shù)量。3：延遲：

響應(yīng)時(shí)間，包括隊(duì)列/

等待時(shí)間，以毫秒為單位。4：飽和度：即過載程度，指標(biāo)與資源利用率相關(guān)，也可通過隊(duì)列深度進(jìn)行直接衡量。5：利用率：

資源或系統(tǒng)的繁忙程度，通常表示為

0%

至

100%。應(yīng)用性能監(jiān)控將前臺(tái)頁面與后端服務(wù)以及用戶網(wǎng)絡(luò)環(huán)境真正串聯(lián)，做到端到端全鏈路、代碼級監(jiān)控。用戶體驗(yàn)評分

前端交互體驗(yàn) 網(wǎng)絡(luò)切片 應(yīng)用調(diào)用拓?fù)?/p>

代碼定位追蹤

業(yè)務(wù)及應(yīng)用質(zhì)量可感知，是監(jiān)控的核心ServerOSDBJ20問題二：海量的日志是否有利用價(jià)值？對于亞健康狀態(tài)，異常日志比系統(tǒng)故障更早出現(xiàn)。由于海量日志存儲(chǔ)在海量網(wǎng)元中，不同廠商日志標(biāo)準(zhǔn)不統(tǒng)一且可讀性差，往往很難鑒別真正觸發(fā)異常的日志。挑戰(zhàn)海量日志保存在海量網(wǎng)元中，缺乏統(tǒng)一視圖不同廠商設(shè)備的日志缺乏統(tǒng)一標(biāo)準(zhǔn)，可讀性差XXXX@%#&(*(

￥%……—*XXXX@#$%&*(%#@#$%CXXXX@!#$*^#$!@%$*(*(^XXXXERROR*&^%$#$*()*^日志統(tǒng)一采集，統(tǒng)一呈現(xiàn)，異廠商設(shè)備日志統(tǒng)一查詢針對異常日志進(jìn)行統(tǒng)計(jì)，實(shí)時(shí)推送異常日志告警，提升亞健康網(wǎng)絡(luò)問題定位效率①跨廠商設(shè)備日志統(tǒng)一查詢②異常日志統(tǒng)計(jì)③異常日志分析與告警推送統(tǒng)一日志分析Syslog網(wǎng)絡(luò)設(shè)備(

Huawei,

HP,

IBM,…)Logstash一體化客服系統(tǒng)精準(zhǔn)扶貧實(shí)名制 語音管控…價(jià)值Cloud

OS

問題二：海量的日志是否有利用價(jià)值？挑戰(zhàn)海量日志保存在海量網(wǎng)21問題三：一個(gè)業(yè)務(wù)監(jiān)控需要添加2480萬個(gè)監(jiān)控項(xiàng)？監(jiān)控內(nèi)容接口平臺(tái)類型（

4）：接入接口，接入渠道，轉(zhuǎn)接接口，轉(zhuǎn)接渠道系統(tǒng)編碼（31）：為各省分公司的編碼監(jiān)控項(xiàng)類型(8）：調(diào)用總數(shù)，成功率，平均耗時(shí)，失敗率，失敗數(shù)，大于1s比率，大于3s比率，大于5s比率監(jiān)控項(xiàng)名稱（500+）：從業(yè)務(wù)數(shù)據(jù)庫實(shí)時(shí)查詢監(jiān)控項(xiàng)名稱錯(cuò)誤碼（50+）：業(yè)務(wù)指標(biāo)的錯(cuò)誤碼類型 （4*31*8*500*50=2480萬）監(jiān)控項(xiàng)類型大：千萬級監(jiān)控項(xiàng)組合，zabbix方案暫無法實(shí)現(xiàn)（包括監(jiān)控配置和展示）圖形展示篩選條件要求可配置，動(dòng)態(tài)關(guān)聯(lián)：zabbix解決方案暫無法實(shí)現(xiàn)（個(gè)性化tag無法關(guān)聯(lián)查詢）。難點(diǎn)說明解決方案利用prometheus靈活的自定義babel功能實(shí)現(xiàn)數(shù)據(jù)采集和動(dòng)態(tài)圖形展示

問題三：一個(gè)業(yè)務(wù)監(jiān)控需要添加2480萬個(gè)監(jiān)控項(xiàng)？監(jiān)控內(nèi)容接22監(jiān)控平臺(tái)架構(gòu)的改進(jìn)與優(yōu)化管控資源對象運(yùn)維數(shù)據(jù)分析平臺(tái)上層運(yùn)維場景應(yīng)用CMDB數(shù)據(jù)庫企業(yè)資源數(shù)據(jù)監(jiān)控底層能力平臺(tái)PrometheusAPMHadoop離線數(shù)據(jù)分析運(yùn)維數(shù)據(jù)分析內(nèi)部用戶物理設(shè)備云平臺(tái) 網(wǎng)絡(luò)一體化客服業(yè)務(wù)監(jiān)控客服設(shè)備監(jiān)控。。。容量管理自動(dòng)化擴(kuò)縮容。。。故障決策系統(tǒng)自動(dòng)化切換。。。Zabbix外部客戶日志 容器云

業(yè)務(wù)監(jiān)控

數(shù)據(jù)庫 應(yīng)用 中間件日志平臺(tái)規(guī)則數(shù)據(jù)機(jī)器學(xué)習(xí)數(shù)據(jù)Flink實(shí)時(shí)數(shù)據(jù)處理運(yùn)維數(shù)據(jù)分析

監(jiān)控平臺(tái)架構(gòu)的改進(jìn)與優(yōu)化管控資源對象運(yùn)維數(shù)據(jù)分析平臺(tái)上層23大型互聯(lián)網(wǎng)公司基礎(chǔ)資源多，業(yè)務(wù)廣，線上變更頻繁，監(jiān)控配置任務(wù)量大監(jiān)控添加不是一蹴而就，需要反復(fù)調(diào)整，重復(fù)工作量大開源工具使用門檻高，大多沒有好用的web界面，需要培訓(xùn)才能靈活使用中移在線公司業(yè)務(wù)/工作人員遍布全國各省，基礎(chǔ)資源達(dá)到上萬級別，業(yè)務(wù)變更頻繁，統(tǒng)一管理難度系數(shù)高痛點(diǎn)應(yīng)對方案12監(jiān)控能力標(biāo)準(zhǔn)化、流程化、模塊化二次開發(fā)、

3自動(dòng)化配置界面化數(shù)據(jù)展示界面化問題四：加不完的監(jiān)控需求？

大型互聯(lián)網(wǎng)公司基礎(chǔ)資源多，業(yè)務(wù)廣，線上變更頻繁，監(jiān)控配置任24中移在線監(jiān)控的歷程（摸著石頭過河）1需求分析與功能驗(yàn)證23全網(wǎng)推廣性能調(diào)優(yōu)典型問題與4軟件bug處理規(guī)范化制定與整改5運(yùn)維界面化與自動(dòng)化欲速則不達(dá)沒有規(guī)范化的交付，質(zhì)量無法保證返工意味著效率降低3倍以上12需求分析與功能驗(yàn)證標(biāo)準(zhǔn)與規(guī)范制定3性能調(diào)優(yōu)典型問題與軟件bug處理4批量推廣5運(yùn)維界面化與自動(dòng)化建議流程（標(biāo)準(zhǔn)先行，質(zhì)量與效率并重）模板、主機(jī)群組、主機(jī)名，主機(jī)顯示名、動(dòng)作名稱、展板內(nèi)容等等需求交付/變更流程，問題處理流程，例行會(huì)議與周報(bào)一點(diǎn)感悟

中移在線監(jiān)控的歷程（摸著石頭過河）1需求分析與功能驗(yàn)證225現(xiàn)在的數(shù)字2.4

萬主機(jī)99

萬觸發(fā)器1.3K動(dòng)作614

萬監(jiān)控項(xiàng)198

萬報(bào)警Proxy92800+ 975DashBoard 用戶數(shù)

現(xiàn)在的數(shù)字2.4萬99萬1.3K614萬198萬報(bào)警26目錄1234背景-全國集中維護(hù)、全球最大出路-選擇開源轉(zhuǎn)型-幾個(gè)問題蛻變-AIOPS在監(jiān)控告警方面的嘗試

目錄1234背景-全國集中維護(hù)、全球最大出路-選擇開源轉(zhuǎn)型-27當(dāng)前的主要矛盾是：海量的告警和有限的專家告警要“少而精”，不要重復(fù)和誤報(bào)監(jiān)控要“多而全”，一個(gè)問題都不能放過！614萬+

監(jiān)控指標(biāo)，99萬+

報(bào)警閾值，

198萬+

告警/天，

2000+

短信/每人每天運(yùn)維主管工程師小明VS.

當(dāng)前的主要矛盾是：海量的告警和有限的專家告警要“少而精”，28經(jīng)過分析，閾值正確設(shè)定是平衡“多而全”和“少而精”的關(guān)鍵手段之一告警正常告警誤報(bào)漏報(bào)缺少壓縮&關(guān)聯(lián)閾值不合理：80%監(jiān)控能力不足：10%人員配置失誤：10%無法設(shè)定閾值：70%無監(jiān)控：30%

經(jīng)過分析，閾值正確設(shè)定是平衡“多而全”和“少而精”的關(guān)鍵手段29閾值設(shè)定從依靠專家經(jīng)驗(yàn)向智能動(dòng)態(tài)設(shè)定演進(jìn)專家依靠經(jīng)驗(yàn)設(shè)定規(guī)則閾值通過大數(shù)據(jù)分析設(shè)定固定閾值通過智能分析動(dòng)態(tài)設(shè)定智能動(dòng)態(tài)閾值

閾值設(shè)定從依靠專家經(jīng)驗(yàn)向智能動(dòng)態(tài)設(shè)定演進(jìn)專家依靠經(jīng)驗(yàn)設(shè)定通30基于結(jié)構(gòu)化的時(shí)序數(shù)據(jù)，通過AI預(yù)測擬合曲線，進(jìn)行異常檢測歷史數(shù)據(jù)分析歷史數(shù)據(jù)讀取和清洗數(shù)據(jù)抽取ETL斷點(diǎn)修復(fù)數(shù)據(jù)間隔調(diào)整自相關(guān)性分析毛刺檢測統(tǒng)計(jì)異常檢測，用于過濾毛刺型異常Moving

Average移動(dòng)平均濾波(ARIMA)Exponential

Smoothing指數(shù)平滑濾波

(Holt-Winters)N*sigma統(tǒng)計(jì)檢測指標(biāo)預(yù)測LSTM（長短期記憶）預(yù)測算法孤立森林（IsolationForest）日同比（Day

overDaymethod）箱線圖（Box-whisker

plot）異常判定途徑一：N-sigma方差途徑二：專家標(biāo)記

基于結(jié)構(gòu)化的時(shí)序數(shù)據(jù)，通過AI預(yù)測擬合曲線，進(jìn)行異常檢測歷史31智能化運(yùn)維并不是我們想象的那樣遙不可及告警覆蓋率提升到95%告警配置人力下降60%告警準(zhǔn)確率提升到80%數(shù)據(jù)算法計(jì)算海量數(shù)據(jù)源（性能指標(biāo)、日志、告警）可以迭代預(yù)測、迭代標(biāo)注……TensorFlow等成熟算法庫針對不同場景，可選擇不同算法，如LSTM用于趨勢預(yù)測、ARIMA用于回歸過濾異常輕量化虛擬機(jī)部署，4C32G即可起步

智能化運(yùn)維并不是我們想象的那樣遙不可及告警覆蓋率提升到9532未來讓智能化在更多運(yùn)維領(lǐng)域落地開花智能故障發(fā)現(xiàn)日志異常檢測、告警壓縮&關(guān)聯(lián)、告警規(guī)則生成、容量管理、性能管理等深度廣度

未來讓智能化在更多運(yùn)維領(lǐng)域落地開花智能故障發(fā)現(xiàn)日志異常檢測33系統(tǒng)架構(gòu)師、運(yùn)維開發(fā)、應(yīng)用運(yùn)維、數(shù)據(jù)庫運(yùn)維、大數(shù)據(jù)運(yùn)維、數(shù)據(jù)分析、容器云開發(fā)、云計(jì)算開發(fā)、JAVA開發(fā)享受互聯(lián)網(wǎng)般技術(shù)挑戰(zhàn)國企穩(wěn)定待遇鄭州、北京、上海、深圳研發(fā)中心，31省會(huì)城市與客戶交互產(chǎn)生的海量數(shù)據(jù)，包括語音、文本、圖像等數(shù)據(jù)公司年輕、人員年輕、扁平化管理

系統(tǒng)架構(gòu)師、運(yùn)維開發(fā)、應(yīng)用運(yùn)維、數(shù)據(jù)庫運(yùn)維、大數(shù)據(jù)運(yùn)維、數(shù)據(jù)34謝謝

謝謝35全球最大呼叫平臺(tái)監(jiān)控實(shí)踐之路

全球最大呼叫平臺(tái)監(jiān)控實(shí)踐之路36目錄背景-全國集中維護(hù)、全球最大1出路-選擇開源2轉(zhuǎn)型-幾個(gè)問題3蛻變-AIOPS在監(jiān)控報(bào)警方面的嘗試4

目錄背景-全國集中維護(hù)、全球最大1出路-選擇開源2轉(zhuǎn)型-幾個(gè)37中移在線公司移動(dòng)全網(wǎng)集中服務(wù)提供者移動(dòng)全網(wǎng)業(yè)務(wù)后臺(tái)集中處理者移動(dòng)全網(wǎng)渠道運(yùn)營集中支撐者201431省呼叫業(yè)務(wù)完成劃轉(zhuǎn)奠定全網(wǎng)集中化運(yùn)營基礎(chǔ)2016實(shí)現(xiàn)盈利業(yè)務(wù)發(fā)展和改革創(chuàng)新初見成效全集團(tuán)首批入選國資委國企改革“雙百行動(dòng)”三家公司之一2018201710月注冊成立全集團(tuán)集中化、專業(yè)化運(yùn)營試驗(yàn)田發(fā)展歷程

中移在線公司移動(dòng)全網(wǎng)集中服務(wù)提供者移動(dòng)全網(wǎng)業(yè)務(wù)后臺(tái)集中處理38傳統(tǒng)呼叫中心傳統(tǒng)呼叫中心是基于PBX、專用硬件排隊(duì)機(jī)、硬件語音板卡等專用設(shè)備組成的客服系統(tǒng)。軟硬一體，不夠靈活建設(shè)成本高、周期長、維護(hù)升級困難無法滿足多渠道多媒體互聯(lián)網(wǎng)相關(guān)增值業(yè)務(wù)的融合無法實(shí)現(xiàn)多客服中心坐席跨網(wǎng)協(xié)同無法快速響應(yīng)業(yè)務(wù)需求缺點(diǎn)排隊(duì)機(jī)CTIIVR應(yīng)用PSTN/PLMNPBX坐席坐席

傳統(tǒng)呼叫中心傳統(tǒng)呼叫中心是基于PBX、專用硬件排隊(duì)機(jī)、硬件語39新形態(tài)呼叫中心語音坐席視頻坐席互聯(lián)網(wǎng)坐席熱線互聯(lián)網(wǎng)新形態(tài)下的呼叫中心質(zhì)量管控大數(shù)據(jù)平臺(tái)支持客戶全渠道交互智能質(zhì)檢智能導(dǎo)航智能應(yīng)答轉(zhuǎn)人工智能知識庫坐席助手語音客服視頻客服在線客服智能IVR智能運(yùn)營運(yùn)營管理呼叫平臺(tái)統(tǒng)一排隊(duì)統(tǒng)一路由統(tǒng)一監(jiān)控純軟件：全媒體CTI、IVR、互聯(lián)網(wǎng)接入網(wǎng)關(guān)、軟交換、中繼網(wǎng)關(guān)、媒體加速服務(wù)、用戶終端富媒體：支持傳統(tǒng)語音、文本、圖片、視頻、短語音、微信、微博智能化：與人工智能（AI）、大數(shù)據(jù)技術(shù)結(jié)合，應(yīng)用于IVR、機(jī)器人應(yīng)答、質(zhì)檢、外呼等集中化：接續(xù)、CRM、分析、質(zhì)檢、話務(wù)監(jiān)控等集中化特征

新形態(tài)呼叫中心語音坐席視頻坐席互聯(lián)網(wǎng)坐席熱線互聯(lián)網(wǎng)新形40在線公司:

全球最大呼叫中心河南江蘇北京我們面臨的運(yùn)維挑戰(zhàn)多難高用戶多,

IT規(guī)模接近一線互聯(lián)網(wǎng)企業(yè)9億用戶,

超1億微信粉絲，月服務(wù)超億次，微博矩陣粉絲3038萬（居行業(yè)首位），10086APP超五千萬用戶量20000+服務(wù)器50000+Tomcat業(yè)務(wù)變化快，運(yùn)維環(huán)境復(fù)雜支撐全國營銷活動(dòng)，總部/分公司/省公司多級協(xié)同日均上線

17

次，日處理

206

例工單技術(shù)新：微服務(wù)/云計(jì)算/容器

…要求高，提供電信級服務(wù)99.99%

的可靠性15秒接通要求7*24

小時(shí)保障

在線公司:全球最大呼叫中心河南江蘇北京我們面臨的運(yùn)維挑戰(zhàn)多41轉(zhuǎn)變運(yùn)維思路，適應(yīng)新的時(shí)代挑戰(zhàn)為了支持業(yè)務(wù)快速上線和高效運(yùn)維。在線公司監(jiān)控系統(tǒng)需具備敏捷、集中、自動(dòng)、智能的關(guān)鍵能力。自動(dòng)敏捷之前能力建設(shè)智能現(xiàn)在監(jiān)控能力周粒度提供監(jiān)控能力分鐘級提供按專業(yè)劃分的“煙囪式監(jiān)控”混合集中化監(jiān)控手工添加基于策略的自動(dòng)化閉環(huán)依賴專家經(jīng)驗(yàn)基于AI和大數(shù)據(jù)的自動(dòng)識別集中

轉(zhuǎn)變運(yùn)維思路，適應(yīng)新的時(shí)代挑戰(zhàn)為了支持業(yè)務(wù)快速上線和高效運(yùn)維42目錄1234背景-全國集中維護(hù)、全球最大出路-選擇開源轉(zhuǎn)型-幾個(gè)問題蛻變-AIOPS在監(jiān)控報(bào)警方面的嘗試

目錄1234背景-全國集中維護(hù)、全球最大出路-選擇開源轉(zhuǎn)型-43統(tǒng)一監(jiān)控平臺(tái)：開源工具+二次開發(fā)，自主核心可控監(jiān)控管理Grafana統(tǒng)一門戶ITSM運(yùn)維平臺(tái)自動(dòng)化平臺(tái)CMDB統(tǒng)一告警平臺(tái)統(tǒng)一事件分析告警告警接口性能看板告警事件管理短信郵件工單信息故障定位或修復(fù)場景業(yè)務(wù)看板根因分析業(yè)務(wù)建模業(yè)務(wù)模型和配置數(shù)據(jù)被管環(huán)境Java

App.NET

AppPHP,Python,

NodeJS應(yīng)用系統(tǒng)客服系統(tǒng)監(jiān)控（I2000）應(yīng)用性能監(jiān)控（APM）告警信息場景執(zhí)行調(diào)用性能看板業(yè)務(wù)看板業(yè)務(wù)數(shù)據(jù)PrometheusmetricElasticSearch數(shù)據(jù)庫數(shù)據(jù)庫監(jiān)控（Prometheus）基礎(chǔ)架構(gòu)監(jiān)控（Zabbix）CTI/UAP系統(tǒng)服務(wù)器、網(wǎng)絡(luò)、存儲(chǔ)、虛擬化環(huán)境等告警看板Kafka實(shí)時(shí)融合監(jiān)控：引入業(yè)界開源工具，進(jìn)行二次開發(fā)與封裝，形成核心自主可控、穩(wěn)定高效、海量秒級的監(jiān)控能力?？缬?跨廠商/跨層的IT/CT實(shí)時(shí)融合監(jiān)控。有豐富的管理對象。多樣靈活的數(shù)據(jù)展現(xiàn)形式，可以靈活配置，適應(yīng)不同場景，快速定制。監(jiān)控?cái)?shù)據(jù)

統(tǒng)一監(jiān)控平臺(tái)：開源工具+二次開發(fā)，自主核心可控監(jiān)控管理Gra44統(tǒng)一監(jiān)控平臺(tái)：集中建設(shè)、統(tǒng)一管控、邊緣節(jié)點(diǎn)標(biāo)準(zhǔn)化為了更快速的建立監(jiān)控能力、更全面的管控系統(tǒng)質(zhì)量，在線服務(wù)公司統(tǒng)一監(jiān)控平臺(tái)采用了總部集中建設(shè)、統(tǒng)一管控，分公司標(biāo)準(zhǔn)化接入的建設(shè)模式。全網(wǎng)集中：總部負(fù)責(zé)監(jiān)控能力建設(shè)、邊緣節(jié)點(diǎn)的標(biāo)準(zhǔn)化，所有監(jiān)控?cái)?shù)據(jù)的上收、分析、展現(xiàn)與通知。分公司提供資源，遵照標(biāo)準(zhǔn)化、封裝后的監(jiān)控模板進(jìn)行監(jiān)控資源的維護(hù)與管理。

統(tǒng)一監(jiān)控平臺(tái)：集中建設(shè)、統(tǒng)一管控、邊緣節(jié)點(diǎn)標(biāo)準(zhǔn)化為了更快速的45一些小總結(jié)：半年時(shí)間2萬200

萬90

萬30

萬主機(jī)監(jiān)控項(xiàng)觸發(fā)器報(bào)警84400+5451.3KProxyDashBoard用戶數(shù)動(dòng)作

一些小總結(jié)：半年時(shí)間2萬200萬90萬30萬主機(jī)監(jiān)控46一些小總結(jié)：廣泛、豐富、多樣、靈活

一些小總結(jié)：廣泛、豐富、多樣、靈活47網(wǎng)絡(luò)設(shè)備類型與廠家存活/丟包/時(shí)延CPU/內(nèi)存占用率snmp狀態(tài)溫度端口狀態(tài)出/入口帶寬利用率出/入口丟、錯(cuò)包接口類型設(shè)備狀態(tài) 網(wǎng)卡狀態(tài) 設(shè)備信息端口描述軟件版本系統(tǒng)名稱光功率光模塊接收功率網(wǎng)絡(luò)協(xié)議光模塊發(fā)送 BGP對等體功率 連接狀態(tài)ospf鄰居狀態(tài)vrrp虛擬路由狀態(tài)網(wǎng)絡(luò)監(jiān)控指標(biāo)SNMP一些小總結(jié)：廣泛、豐富、多樣、靈活

網(wǎng)絡(luò)設(shè)備類型與廠家存活/丟包/時(shí)延CPU/內(nèi)存占用率sn48一些小總結(jié)：廣泛、豐富、多樣、靈活看板可靈活制定，分鐘級完成配置。圖表多樣化展現(xiàn)：折線圖、柱狀圖、餅圖、區(qū)域圖、拓?fù)鋱D等。

一些小總結(jié)：廣泛、豐富、多樣、靈活看板可靈活制定，分鐘級完成49主機(jī)參數(shù)內(nèi)核參數(shù)TCP協(xié)議棧參數(shù)信號量/IO（Zabbix啟動(dòng)失敗不釋放信號集）數(shù)據(jù)庫CPU/內(nèi)存/IO連接（最大連接數(shù)、超時(shí)時(shí)長）數(shù)據(jù)一致性強(qiáng)烈建議采用數(shù)據(jù)庫SSD硬盤WEBNginx參數(shù)Php參數(shù)php.ini：max_input_vars（影響模板應(yīng)用大批量主機(jī)失?。㈱abbix視具體需求配置啟動(dòng)模塊和進(jìn)程數(shù)禁用自動(dòng)發(fā)現(xiàn)，采用腳本調(diào)用api實(shí)現(xiàn)禁用housekeeper，啟用數(shù)據(jù)庫表分區(qū)禁用server直連agent配置參數(shù)優(yōu)化defines.inc.php：QUEUE_DETAIL_ITEM_COUNT（定義監(jiān)控項(xiàng)隊(duì)列檢索限制，影響消息隊(duì)列積壓顯示）一些小總結(jié)：zabbix系統(tǒng)優(yōu)化

主機(jī)參數(shù)數(shù)據(jù)庫WEBZabbix一些小總結(jié)：zabbix系統(tǒng)50一些小總結(jié)：zabbix系統(tǒng)優(yōu)化二、Preprocessing

manager

負(fù)荷長期為100%三、Zabbix

server主機(jī)反復(fù)重啟，卻無法啟動(dòng)成功問題現(xiàn)象與影響一、大量消息隊(duì)列積壓（超過20萬），且呈現(xiàn)雪崩效應(yīng)問題定位與解決方案一、zabbix官網(wǎng)對于pre-process耗盡的說明：二、解決方案：1、在zabbix

server所在主機(jī)再單獨(dú)部署一個(gè)proxy節(jié)點(diǎn)。2、將之前由zabbix

server直接監(jiān)控的所有proxy所在主機(jī)的agent節(jié)點(diǎn)，全部轉(zhuǎn)到新增proxy管理。3、降低server的pollers、java

pollers、pingers、trappers等進(jìn)程數(shù)配置。4、增加zabbix

server的自監(jiān)控項(xiàng)配置項(xiàng)及告警（

Pre-process進(jìn)程占用率及zabbix_server.log的異常關(guān)鍵字告警）。

一些小總結(jié)：zabbix系統(tǒng)優(yōu)化二、Preprocessin51Zabbix配置的同步機(jī)制Zabbix的配置表比較多，大容量局點(diǎn)關(guān)聯(lián)查詢sql耗時(shí)很長如數(shù)據(jù)庫控制sql執(zhí)行時(shí)間的max_execution_time配置不合理，會(huì)導(dǎo)致無法將相應(yīng)配置表數(shù)據(jù)同步到zabbix

server以及proxy的cache，從而導(dǎo)致出現(xiàn)大量監(jiān)控項(xiàng)無法正常采集及消息隊(duì)列積壓現(xiàn)象。以下為zabbix_server.log相應(yīng)日志：數(shù)據(jù)庫sql執(zhí)行超時(shí)配置建議根據(jù)現(xiàn)網(wǎng)的數(shù)據(jù)庫IO處理性能以及局點(diǎn)規(guī)模合理配置數(shù)據(jù)庫超時(shí)相關(guān)參數(shù)，將max_execution_time設(shè)置為超過目前zabbix

server同步配置sql執(zhí)行時(shí)長的2倍以上，并定期檢查zabbix_server.log日志的相應(yīng)執(zhí)行時(shí)長，或者增加自監(jiān)控告警。一些小總結(jié)：zabbix系統(tǒng)優(yōu)化

Zabbix配置的同步機(jī)制Zabbix的配置表比較多，大容量52目錄1234背景-全國集中維護(hù)、全球最大出路-選擇開源轉(zhuǎn)型-幾個(gè)問題蛻變-AIOPS在監(jiān)控告警方面的嘗試

目錄1234背景-全國集中維護(hù)、全球最大出路-選擇開源轉(zhuǎn)型-53問題一：200w監(jiān)控指標(biāo)，業(yè)務(wù)出了問題仍然不知道治理范圍應(yīng)用系統(tǒng)管理業(yè)務(wù)質(zhì)量管理客戶體驗(yàn)管理能力擴(kuò)展基礎(chǔ)設(shè)施管理基礎(chǔ)設(shè)施性能管理(PM)基礎(chǔ)設(shè)施故障管理(FM)用戶問題管理用戶感知管理業(yè)務(wù)問題管理業(yè)務(wù)質(zhì)量管理以業(yè)務(wù)質(zhì)量和客戶體驗(yàn)為核心，以可管控、可視化、可度量為目標(biāo)。全網(wǎng)集中建設(shè)、集中管控、邊緣節(jié)點(diǎn)標(biāo)準(zhǔn)化接入。軟件監(jiān)控+硬件監(jiān)控一網(wǎng)打盡，運(yùn)維數(shù)據(jù)統(tǒng)一、融合、流動(dòng)，建立多層次度量體系。以用戶體驗(yàn)出發(fā)，建立端到端全鏈路監(jiān)控，告警+投訴預(yù)警+客服聯(lián)動(dòng)形成完整閉環(huán)管理。運(yùn)維保障應(yīng)用性能管理(PM)應(yīng)用故障管理(FM)流程及自動(dòng)化管理

問題一：200w監(jiān)控指標(biāo)，業(yè)務(wù)出了問題仍然不知道治理范圍應(yīng)54業(yè)務(wù)及應(yīng)用質(zhì)量可感知，是監(jiān)控的核心ServerOSDBJVMMQWEB面向基礎(chǔ)架構(gòu)的監(jiān)控只能發(fā)現(xiàn)約30%的問題從用戶體驗(yàn)出發(fā)面向應(yīng)用的監(jiān)控能發(fā)現(xiàn)約70%的問題最終用戶體驗(yàn)應(yīng)用程序基礎(chǔ)架構(gòu)梳理業(yè)務(wù)系統(tǒng)核心功能模塊梳理功能模塊的核心監(jiān)控指標(biāo)評審監(jiān)控指標(biāo)的提取方式及有效性監(jiān)控看板制作在強(qiáng)化基礎(chǔ)設(shè)置監(jiān)控的基礎(chǔ)上，補(bǔ)充應(yīng)用性能監(jiān)控和業(yè)務(wù)質(zhì)量監(jiān)控能力，保障業(yè)務(wù)的穩(wěn)定性和客戶感知。應(yīng)用性能監(jiān)控 業(yè)務(wù)質(zhì)量監(jiān)控參考Google

SRE五項(xiàng)黃金指標(biāo)1：速率：請求速率，請每秒請求數(shù)量。2：錯(cuò)誤：

錯(cuò)誤率，即每秒錯(cuò)誤數(shù)量。3：延遲：

響應(yīng)時(shí)間，包括隊(duì)列/

等待時(shí)間，以毫秒為單位。4：飽和度：即過載程度，指標(biāo)與資源利用率相關(guān)，也可通過隊(duì)列深度進(jìn)行直接衡量。5：利用率：

資源或系統(tǒng)的繁忙程度，通常表示為

0%

至

100%。應(yīng)用性能監(jiān)控將前臺(tái)頁面與后端服務(wù)以及用戶網(wǎng)絡(luò)環(huán)境真正串聯(lián)，做到端到端全鏈路、代碼級監(jiān)控。用戶體驗(yàn)評分

前端交互體驗(yàn) 網(wǎng)絡(luò)切片 應(yīng)用調(diào)用拓?fù)?/p>

代碼定位追蹤

業(yè)務(wù)及應(yīng)用質(zhì)量可感知，是監(jiān)控的核心ServerOSDBJ55問題二：海量的日志是否有利用價(jià)值？對于亞健康狀態(tài)，異常日志比系統(tǒng)故障更早出現(xiàn)。由于海量日志存儲(chǔ)在海量網(wǎng)元中，不同廠商日志標(biāo)準(zhǔn)不統(tǒng)一且可讀性差，往往很難鑒別真正觸發(fā)異常的日志。挑戰(zhàn)海量日志保存在海量網(wǎng)元中，缺乏統(tǒng)一視圖不同廠商設(shè)備的日志缺乏統(tǒng)一標(biāo)準(zhǔn)，可讀性差XXXX@%#&(*(

￥%……—*XXXX@#$%&*(%#@#$%CXXXX@!#$*^#$!@%$*(*(^XXXXERROR*&^%$#$*()*^日志統(tǒng)一采集，統(tǒng)一呈現(xiàn)，異廠商設(shè)備日志統(tǒng)一查詢針對異常日志進(jìn)行統(tǒng)計(jì)，實(shí)時(shí)推送異常日志告警，提升亞健康網(wǎng)絡(luò)問題定位效率①跨廠商設(shè)備日志統(tǒng)一查詢②異常日志統(tǒng)計(jì)③異常日志分析與告警推送統(tǒng)一日志分析Syslog網(wǎng)絡(luò)設(shè)備(

Huawei,

HP,

IBM,…)Logstash一體化客服系統(tǒng)精準(zhǔn)扶貧實(shí)名制 語音管控…價(jià)值Cloud

OS

問題二：海量的日志是否有利用價(jià)值？挑戰(zhàn)海量日志保存在海量網(wǎng)56問題三：一個(gè)業(yè)務(wù)監(jiān)控需要添加2480萬個(gè)監(jiān)控項(xiàng)？監(jiān)控內(nèi)容接口平臺(tái)類型（

4）：接入接口，接入渠道，轉(zhuǎn)接接口，轉(zhuǎn)接渠道系統(tǒng)編碼（31）：為各省分公司的編碼監(jiān)控項(xiàng)類型(8）：調(diào)用總數(shù)，成功率，平均耗時(shí)，失敗率，失敗數(shù)，大于1s比率，大于3s比率，大于5s比率監(jiān)控項(xiàng)名稱（500+）：從業(yè)務(wù)數(shù)據(jù)庫實(shí)時(shí)查詢監(jiān)控項(xiàng)名稱錯(cuò)誤碼（50+）：業(yè)務(wù)指標(biāo)的錯(cuò)誤碼類型 （4*31*8*500*50=2480萬）監(jiān)控項(xiàng)類型大：千萬級監(jiān)控項(xiàng)組合，zabbix方案暫無法實(shí)現(xiàn)（包括監(jiān)控配置和展示）圖形展示篩選條件要求可配置，動(dòng)態(tài)關(guān)聯(lián)：zabbix解決方案暫無法實(shí)現(xiàn)（個(gè)性化tag無法關(guān)聯(lián)查詢）。難點(diǎn)說明解決方案利用prometheus靈活的自定義babel功能實(shí)現(xiàn)數(shù)據(jù)采集和動(dòng)態(tài)圖形展示

問題三：一個(gè)業(yè)務(wù)監(jiān)控需要添加2480萬個(gè)監(jiān)控項(xiàng)？監(jiān)控內(nèi)容接57監(jiān)控平臺(tái)架構(gòu)的改進(jìn)與優(yōu)化管控資源對象運(yùn)維數(shù)據(jù)分析平臺(tái)上層運(yùn)維場景應(yīng)用CMDB數(shù)據(jù)庫企業(yè)資源數(shù)據(jù)監(jiān)控底層能力平臺(tái)PrometheusAPMHadoop離線數(shù)據(jù)分析運(yùn)維數(shù)據(jù)分析內(nèi)部用戶物理設(shè)備云平臺(tái) 網(wǎng)絡(luò)一體化客服業(yè)務(wù)監(jiān)控客服設(shè)備監(jiān)控。。。容量管理自動(dòng)化擴(kuò)縮容。。。故障決策系統(tǒng)自動(dòng)化切換。。。Zabbix外部客戶日志 容器云

業(yè)務(wù)監(jiān)控

數(shù)據(jù)庫 應(yīng)用 中間件日志平臺(tái)規(guī)則數(shù)據(jù)機(jī)器學(xué)習(xí)數(shù)據(jù)Flink實(shí)時(shí)數(shù)據(jù)處理運(yùn)維數(shù)據(jù)分析

監(jiān)控平臺(tái)架構(gòu)的改進(jìn)與優(yōu)化管控資源對象運(yùn)維數(shù)據(jù)分析平臺(tái)上層58大型互聯(lián)網(wǎng)公司基礎(chǔ)資源多，業(yè)務(wù)廣，線上變更頻繁，監(jiān)控配置任務(wù)量大監(jiān)控添加不是一蹴而就，需要反復(fù)調(diào)整，重復(fù)工作量大開源工具使用門檻高，大多沒有好用的web界面，需要培訓(xùn)才能靈活使用中移在線公司業(yè)務(wù)/工作人員遍布全國各省，基礎(chǔ)資源達(dá)到上萬級別，業(yè)務(wù)變更頻繁，統(tǒng)一管理難度系數(shù)高痛點(diǎn)應(yīng)對方案12監(jiān)控能力標(biāo)準(zhǔn)化、流程化、模塊化二次開發(fā)、

3自動(dòng)化配置界面化數(shù)據(jù)展示界面化問題四：加不完的監(jiān)控需求？

大型互聯(lián)網(wǎng)公司基礎(chǔ)資源多，業(yè)務(wù)廣，線上變更頻繁，監(jiān)控配置任59中移在線監(jiān)控的歷程（摸著石頭過河）1需求分析與功能驗(yàn)證23全網(wǎng)推廣性能調(diào)優(yōu)典型問題與4軟件bug處理規(guī)范化制定與整改5運(yùn)維界面化與自動(dòng)化欲速則不達(dá)沒有規(guī)范化的交付，質(zhì)量無法保證返工意味著效率降低3倍以上12需求分析與功能驗(yàn)證標(biāo)準(zhǔn)與規(guī)范制定3性能調(diào)優(yōu)典型問題與軟件bug處理4批量推廣