[[319833]]

說(shuō)明：本文為網(wǎng)易游戲監(jiān)控團(tuán)隊(duì)負(fù)責(zé)人王維棟老師在 GOPS 2019 · 上海站的分享整理而成。

作者簡(jiǎn)介

王維棟，網(wǎng)易游戲監(jiān)控團(tuán)隊(duì)負(fù)責(zé)人

我跟大家介紹一下我們是如何在游戲領(lǐng)域做到千億級(jí)的監(jiān)控體系，還有我們?cè)谥悄鼙O(jiān)控方面的一些探索。

我是網(wǎng)易游戲監(jiān)控團(tuán)隊(duì)的負(fù)責(zé)人，7年時(shí)間一直在做運(yùn)維平臺(tái)相關(guān)的開(kāi)發(fā)工作，擅⻓的領(lǐng)域是智能監(jiān)控以及應(yīng)用性能調(diào)優(yōu)。

我會(huì)分為四個(gè)章節(jié)說(shuō)。

首先就是游戲領(lǐng)域的監(jiān)控會(huì)有什么區(qū)別，全球布局游戲監(jiān)控又有什么樣的挑戰(zhàn)?面對(duì)海量的時(shí)間序列時(shí)我們是如何處理；第三部分說(shuō)說(shuō)在可視化和報(bào)警方面做的比較有亮點(diǎn)的地方，最后講一講我們?cè)谥悄鼙O(jiān)控方面的實(shí)踐。

1. 來(lái)自全球布局的游戲的監(jiān)控挑戰(zhàn)

首先說(shuō)說(shuō)傳統(tǒng)游戲架構(gòu)是什么樣的，以前游戲架構(gòu)大多都是單體架構(gòu)，單服單機(jī)器。另外基礎(chǔ)設(shè)施比較單一，之前基本都是物理機(jī)。

另外，以前基本就是瞄準(zhǔn)國(guó)內(nèi)市場(chǎng)做事情。最后，監(jiān)控的層次也非常簡(jiǎn)單，無(wú)非就是硬件、網(wǎng)絡(luò)、操作系統(tǒng)、進(jìn)程和業(yè)務(wù)指標(biāo)。

 

但現(xiàn)階段，我們面臨的監(jiān)控場(chǎng)景變化的太快了，游戲的架構(gòu)多樣化，混合基礎(chǔ)設(shè)施在我們公司逐漸出現(xiàn)。此外，公司開(kāi)始立足海外，在海外有非常好的增⻓。最后，傳統(tǒng)監(jiān)控也逐漸向可觀測(cè)性去擴(kuò)展。

首先是游戲架構(gòu)的變遷，從最開(kāi)始的單機(jī)架構(gòu)，擴(kuò)展到分布式架構(gòu)。也就是說(shuō)，玩家看到一個(gè)游戲服，在后面會(huì)有十幾臺(tái)機(jī)器，有的甚至多達(dá)百臺(tái)機(jī)器，取決于玩法不同。

后來(lái)，很多游戲的開(kāi)發(fā)接觸到微服務(wù)的概念，開(kāi)始逐漸的把游戲里面比如大廳、聊天服務(wù)從游戲的核心邏輯里面獨(dú)立出來(lái)，變成微服務(wù)，對(duì)游戲服務(wù)提供支持。這種情況下，微服務(wù)場(chǎng)景開(kāi)始逐漸在游戲場(chǎng)景里面出現(xiàn)。

第二方面，我們一直在做游戲上云，一開(kāi)始在物理機(jī)器部署游戲服，后來(lái)做私有云，在虛擬機(jī)上部署。在出海的過(guò)程中也開(kāi)始逐漸采購(gòu)海外的公有云和第三方 IDC 的機(jī)器。

再后來(lái)我們開(kāi)始做容器化，在容器化進(jìn)行到一定程度，現(xiàn)在有一些游戲也開(kāi)始嘗試云原生。但是我們這個(gè)過(guò)程不是一蹴而就的，畢竟體量比較大，而且一個(gè)公司可能會(huì)有幾百個(gè)游戲，在這種場(chǎng)景下就會(huì)出現(xiàn)一個(gè)混合云的狀態(tài)，有些游戲還是物理部署的，有些游戲已經(jīng)云原生了，這種情況下挑戰(zhàn)是非常大的。

另一方面，我們公司目前的游戲業(yè)務(wù)已經(jīng)覆蓋到全球數(shù)十個(gè)國(guó)家，監(jiān)控也會(huì)有二三十個(gè)region 去覆蓋到全球的游戲服務(wù)；此外，我們會(huì)在海外采購(gòu)多個(gè)云服務(wù)商，這種情況下監(jiān)控的挑戰(zhàn)也會(huì)增加。

從傳統(tǒng)監(jiān)控向可觀測(cè)性過(guò)渡的過(guò)程中，我們不僅有報(bào)警、可視化，還有 debugging、profiling。盡力讓系統(tǒng)更加透明、可視化，從而形成更好的理解來(lái)優(yōu)化我們的產(chǎn)品，做到更好的度量，形成一個(gè)良性閉環(huán)。

基于上面這些思路，我們目前的游戲監(jiān)控架構(gòu)是這樣的，從下到上是監(jiān)控?cái)?shù)據(jù)從產(chǎn)生到處理再到消費(fèi)的過(guò)程，然后右邊會(huì)有一些控制層的東⻄，這張圖只畫(huà)出了最關(guān)鍵的一些點(diǎn)。

我們?cè)诓杉瘜用鏁?huì)做很多數(shù)據(jù)入口，比如說(shuō)有 SDK，agent，日志指標(biāo)，還有第三方數(shù)據(jù)庫(kù)。通過(guò)多區(qū)域部署的就近接入層，把這些數(shù)據(jù)接過(guò)來(lái)導(dǎo)到中央，中央會(huì)用一個(gè) kafka 的數(shù)據(jù)隊(duì)列做解耦和路由，支持多系統(tǒng)的數(shù)據(jù)訂閱，此外還有聚合，數(shù)據(jù)存儲(chǔ)。

在數(shù)據(jù)應(yīng)用的迭代過(guò)程中，我們會(huì)有一些歷史包袱，一開(kāi)始是看業(yè)務(wù)場(chǎng)景來(lái)做監(jiān)控的，所以就會(huì)出現(xiàn)一堆數(shù)據(jù)子系統(tǒng)，比如說(shuō)有客戶(hù)端監(jiān)控，用戶(hù)體驗(yàn)的監(jiān)控，有服務(wù)端監(jiān)控，有資源相關(guān)監(jiān)控，有網(wǎng)絡(luò)監(jiān)控，還有性能優(yōu)化的監(jiān)控。

我們目前正在逐一整合，并且對(duì)外提供統(tǒng)一入口。報(bào)警層面是基于一個(gè)標(biāo)準(zhǔn)化的規(guī)則引擎做報(bào)警，現(xiàn)階段我們也在逐漸把異常檢測(cè)，事件關(guān)聯(lián)這些功能加進(jìn)去，此外還有像問(wèn)題生命周期管理、事件升級(jí)來(lái)確保通知可達(dá)等機(jī)制。

最上層我們提供了一些數(shù)據(jù)可視化、報(bào)警通知、實(shí)時(shí)分析、性能優(yōu)化等一系列的能力。控制層面，我們通過(guò)跟 CMDB 深度結(jié)合，訂閱 CMDB 變更來(lái)減少監(jiān)控的配置成本。

通過(guò)區(qū)域管理來(lái)做到全球化的監(jiān)控。我們的 agent 能夠支持到豐富的插件自定義功能，所以有一個(gè)插件倉(cāng)庫(kù)。

最后我們做了一個(gè)命令管道，其實(shí)就是類(lèi)似于像 Ansible 的東⻄，跟我們的 agent 集成，最直接的價(jià)值就是配置的分發(fā)、故障自愈等功能都可以依托這樣的基礎(chǔ)架構(gòu)來(lái)構(gòu)建。

2. 海量時(shí)間序列數(shù)據(jù)處理

接下來(lái)說(shuō)說(shuō)我們面對(duì)海量時(shí)間序列的時(shí)候做的一些事情。首先就是面對(duì)海量而且異構(gòu)的監(jiān)控場(chǎng)景，我們做了監(jiān)控對(duì)象的抽象，所有的監(jiān)控概念都能夠自定義地套進(jìn)去抽象的數(shù)據(jù)模型。

通過(guò)與 CMDB 的結(jié)合，我們做到比較小的管理成本。采集方面，我們給出多種采集方式去適配不同的業(yè)務(wù)場(chǎng)景，然后做了統(tǒng)一的入口，在統(tǒng)一的數(shù)據(jù)總線(xiàn)做了數(shù)據(jù)的對(duì)⻬、預(yù)處理等工作。

最后我們做了一個(gè)大規(guī)模的海量時(shí)間序列存儲(chǔ)。

首先來(lái)說(shuō)監(jiān)控對(duì)象抽象，為什么要做這件事情呢？常規(guī)場(chǎng)景中，我們會(huì)監(jiān)控一個(gè)物理機(jī)、虛擬機(jī)、容器，再到一個(gè)進(jìn)程。對(duì)于CPU、網(wǎng)卡等硬件，只要能標(biāo)注它，就能把數(shù)據(jù)關(guān)聯(lián)上去。

隨著業(yè)務(wù)不斷的擴(kuò)展，在游戲場(chǎng)景里面要監(jiān)控某個(gè)游戲場(chǎng)景， 要監(jiān)控某一次 battle，某一個(gè) NPC 的屬性，游戲進(jìn)程之間 RPC 的情況。這種場(chǎng)景下如果我們寫(xiě)死配置，適配一個(gè)個(gè)場(chǎng)景，對(duì)于監(jiān)控人員來(lái)說(shuō)維護(hù)成本很高。

所以我們做了一層抽象，跟業(yè)界比較流行的方案例如 OpenTSDB、Prometheus有共同之處。

我們把監(jiān)控對(duì)象抽象為 Entity，用 EntityType 描述它是屬于什么類(lèi)型的，用 tags 描述它的屬性，同時(shí) tags 也會(huì)有一個(gè)類(lèi)似交叉表的用途，把 entity 關(guān)聯(lián)在一起。目前我們大概有 100 多個(gè) EntityTypes，差不多500萬(wàn)的 entity，4億級(jí)別的 timeseries。

剛才講到全球就近接入層，這是服務(wù)端監(jiān)控的基礎(chǔ)架構(gòu)。最中間的紅色是一個(gè) Arbiter，它的⻆色是仲裁，負(fù)責(zé)訂閱 CMDB 的變更，生成監(jiān)控配置，監(jiān)控配置就會(huì)被分發(fā)到每一個(gè) region 里面，當(dāng) agent 入網(wǎng)的時(shí)候會(huì)先去詢(xún)問(wèn) Arbiter，我是屬于哪個(gè)region的？

然后 Arbiter 會(huì)告訴它所屬的 region 和 node 列表，agent 嘗試連接，成功就會(huì)入網(wǎng)，它會(huì)跟 node 保持一個(gè)⻓鏈接，把它產(chǎn)生的數(shù)據(jù)全部交給 Node 去中轉(zhuǎn)。node 到中央我們會(huì)做網(wǎng)絡(luò)優(yōu)化，比 agent 直接連到中央會(huì)快很多。

另一方面，保持⻓連接有助于配置同步。配置變更時(shí)，Arbiter會(huì)通過(guò)Node和⻓鏈接，實(shí)時(shí)推送配置下去到 Agent。

這一套架構(gòu)有高可用的保障，首先 Arbiter 是單點(diǎn)，我們做了 Arbiters Active-Standby的模式，出問(wèn)題的時(shí)候 Standby Arbiter 會(huì)接管主 Arbiters 的工作。

Arbiter 的邏輯基本都是冪等的，所以不會(huì)擔(dān)心數(shù)據(jù)和集群一致性的問(wèn)題。Node 會(huì)和 Arbiter 保持心跳，如果 Node 失聯(lián)了，Arbiter 會(huì)把相關(guān)的 Agents 調(diào)度到其他的節(jié)點(diǎn)上去。此外，每個(gè) region 里面會(huì)有多個(gè) node 冗余，在 node 之間分配 agent 時(shí)，我們用了一致性哈希，去確保增刪 node 時(shí)，盡量減少 agent 分配關(guān)系的抖動(dòng)。

這套流程，配置管理部分和數(shù)據(jù)流部分是分離的，上層Arbiter和node完全失聯(lián)的情況下，agent會(huì)跟node一直保持連接，直到接到新的配置。這種情況下，即使我們中央出現(xiàn)了故障，agent仍然會(huì)上報(bào)數(shù)據(jù)。

說(shuō)一下我們的 region 是怎么劃分的，首先我們會(huì)有一批機(jī)器和它們的IP，CMDB 會(huì)用 IDC、ISP 等一系列信息，把IP分類(lèi)，分成 CMDB 的 region。

當(dāng)一個(gè)新的 CMDB region 產(chǎn)生的時(shí)候，我們會(huì)拿到變更事件，根據(jù)地區(qū)、ISP 等幾種條件判斷可能跟哪個(gè) monitor region 比較近，或者相關(guān)的網(wǎng)絡(luò)質(zhì)量比較好，然后在幾個(gè)候選 regions 中選一些點(diǎn)，跟新的 region 發(fā)起互相探測(cè)的任務(wù)，得到 rtt and loss。

管理員可以看到 一個(gè)包含這些數(shù)據(jù)的可供決策的列表，只要去選一個(gè) monitor region，新的cmdb region 就會(huì)自動(dòng)加入到 monitor region。

最小管理成本則是通過(guò)訂閱 CMDBS 的變更實(shí)現(xiàn)的，我們的 SRE 通過(guò)各種管理系統(tǒng)和 CMDB，來(lái)管理一些資源和業(yè)務(wù)的對(duì)應(yīng)關(guān)系。

Arbiter 對(duì)需要生成配置的數(shù)據(jù)，做一個(gè)內(nèi)存的 ORM，同時(shí)在 CMDB 接一個(gè) db trigger，把它所有增刪改的事件打到 MQ， 在 arbiter 訂閱，實(shí)時(shí)更新 ORM。

然后基于這個(gè) ORM 做配置生成，這些配置生成完之后就會(huì)推到 region nodes，然后推到 agent 去，最初這個(gè)架構(gòu)做完之后，我們可以實(shí)現(xiàn)秒級(jí)的配置更新，但是后續(xù)規(guī)模變的非常龐大，維持秒級(jí)配置更新使用的資源不劃算，所以后續(xù)在這里面加了窗口，十秒或者一分鐘內(nèi)變更的事件，我們會(huì)統(tǒng)一分 發(fā)，盡量減少配置的抖動(dòng)。

在數(shù)據(jù)采集方面，因?yàn)橛螒蛎媾R的場(chǎng)景非常多，所以我們提供了多個(gè)采集方式。

首先就是 agent 插件，它通過(guò)服務(wù)綁定到機(jī)器，在機(jī)器上采集數(shù)據(jù)然后推出去。主動(dòng)監(jiān)控的 checker 插件也是類(lèi)似的方案，我們提供各個(gè) region 的探測(cè)點(diǎn)，做從外部發(fā)起的主動(dòng)探測(cè)。此外也有一套框架，能讓用戶(hù)自己配置，從任意一臺(tái)主機(jī)上發(fā)起探測(cè)。

主動(dòng)監(jiān)控支持 icmp/tcp/http 等一系列協(xié)議。此外，SRE 可以直接開(kāi)發(fā)插件，覆蓋到業(yè)務(wù)協(xié)議。

第三個(gè)方式是 pusher，我們提供一套 SDK 和 server 端，主要場(chǎng)景是由進(jìn)程內(nèi)向外 push 數(shù)據(jù)。游戲開(kāi)發(fā)只要把 SDK 引入到自己的代碼，調(diào)用幾個(gè)接口，然后就可以 push 數(shù)據(jù)。目標(biāo)就是能夠?qū)崿F(xiàn)任意環(huán)境下的數(shù)據(jù)push接口。

最后，游戲經(jīng)常使用日志暴露一些統(tǒng)計(jì)指標(biāo)，這種情況下我們也做了 log metric 的兼容，從實(shí)時(shí)日志流里過(guò)濾一些標(biāo)準(zhǔn)字段，把它直接導(dǎo)到監(jiān)控?cái)?shù)據(jù)流。

此外，公司也在嘗試云原生的方案，所以我們也引入了 prometheus，我們集成了它的服務(wù)發(fā)現(xiàn)模塊，然后直接對(duì)接 prometheus exporter 的協(xié)議，用一組分布式的 agent 去拉exporter 暴露出的數(shù)據(jù)，這樣 k8s、etcd 等系統(tǒng)的監(jiān)控就可以直接對(duì)接。

對(duì)于容器的監(jiān)控，我們用插件封裝了 cadvisor。為了兼容公司內(nèi)其他的時(shí)間序列數(shù)據(jù)，我們提供了第三方 db 的 adapter，用來(lái)從其他的DB里面導(dǎo)數(shù)據(jù)。

有了這些數(shù)據(jù)采集方式，我們就可以比較從容應(yīng)對(duì)混合云下的監(jiān)控場(chǎng)景。

對(duì)于物理機(jī)和虛擬機(jī)，跑 agent，SRE 按需編寫(xiě)和綁定插件；對(duì)于容器，我們比較傾向于用 pusher 或日志導(dǎo)出數(shù)據(jù)；對(duì)于比較固定的場(chǎng)景也支持從宿主直接 attach 到容器采集數(shù)據(jù)；云原生的場(chǎng)景使用 Cadvisor、Prometheus Exporter、日志指標(biāo)等。

剛剛提到我們 agent 是插件化的框架，目前我們是用 Python 做這套 agent 的，所以對(duì)于 SRE 來(lái)說(shuō)上手成本非常低。

SRE 想要開(kāi)發(fā)一個(gè)插件，就可以在系統(tǒng)點(diǎn)一下，得到一個(gè) Gitlab 的 repo，在代碼框架里面填采集數(shù)據(jù)的代碼，push 上去。

只要 push 到保護(hù)分支，就會(huì)自動(dòng)打成一個(gè)pip包，然后丟到 pip 源上面去。接下來(lái)只需要服務(wù)綁定 插件，這些服務(wù)的機(jī)器就會(huì)get到這個(gè)配置，然后 agent 就會(huì)裝這個(gè)插件去跑。

現(xiàn)階段我們已經(jīng)800多個(gè)Python插件，覆蓋了絕大多數(shù)的業(yè)務(wù)場(chǎng)景。包括前面講到 的多點(diǎn)探測(cè)、故障自愈相關(guān)功能都是通過(guò)插件支持的。

當(dāng)數(shù)據(jù)收集上來(lái)之后，我們有一個(gè)統(tǒng)一總線(xiàn)做處理。首先所有數(shù)據(jù)都會(huì)進(jìn)到一個(gè) Kafka Origin Data Topics 里，然后 PreProcessor 做一些數(shù)據(jù)清洗，過(guò)濾非法數(shù)據(jù)。做數(shù)據(jù)對(duì)⻬，然后進(jìn)入 MainFlow。

進(jìn)到 MainFlow ，我們會(huì)有一個(gè) Flink Aggregator 去負(fù)責(zé)做聚合，用戶(hù)會(huì)在系統(tǒng)上配 一些可視化和報(bào)警規(guī)則，按這些規(guī)則延生成一些統(tǒng)一規(guī)范下的聚合規(guī)則，F(xiàn)link 規(guī)則聚合數(shù)據(jù)，再把聚合好的數(shù)據(jù)丟回 MainFlow。

后面會(huì)有幾個(gè)系統(tǒng)去訂閱，首先是存儲(chǔ)，然后周邊系統(tǒng)會(huì) Subscriber，然后是 Visualization Updater 會(huì)做自動(dòng)的可視化方案生成，最后就是報(bào)警。

這里是一個(gè)存儲(chǔ)的架構(gòu)， Kafka 的 MainFlow 在存儲(chǔ)這邊對(duì)接了三個(gè)模塊。首先是 存儲(chǔ)架構(gòu)，我們把 metadata 和時(shí)序數(shù)據(jù)分開(kāi)了。Metadata 是描述 Metrics 的 Tags 以及跟 Entity關(guān)系的數(shù)據(jù)， 我們把它全部拆出來(lái)，生成 UUID，接下來(lái)存儲(chǔ)的 時(shí)候拿這個(gè) UUID 和 TimeSeries 存在一起。

Redis 的集群會(huì)緩存六個(gè)小時(shí)數(shù)據(jù)，會(huì)有一個(gè)模塊每半個(gè)小時(shí)把數(shù)據(jù) merge dump一 次，在 mongodb 這邊分了幾個(gè)粒度的庫(kù)，有1分鐘，有5分鐘，有30分鐘還有一天。Archive 模塊每天跑一次，負(fù)責(zé)把 MongDB 中的數(shù)據(jù)歸檔到 hdfs。

接下來(lái)第三個(gè)模塊是 Visualization Updater，通過(guò)訂閱數(shù)據(jù)，按數(shù)據(jù)的組織形式來(lái) 生成與數(shù)據(jù)相對(duì)應(yīng)的可視化的配置。大部分情況下用戶(hù)只要推數(shù)據(jù)，就可以在系統(tǒng) 中看到圖表，接下來(lái)他想要定制細(xì)化、業(yè)務(wù)化的一些視圖的時(shí)候，可以再拖拉這些圖表。

用戶(hù)或者第三方的下游平臺(tái)會(huì)通過(guò)我們統(tǒng)一API和UI拉數(shù)據(jù)，拉數(shù)據(jù)的過(guò)程有一個(gè)策略讀的模塊，這個(gè)模塊主要責(zé)任決定從哪里讀數(shù)據(jù)，按用戶(hù)的query索引到要取哪些 UUID的數(shù)據(jù)，然后接下來(lái)按用戶(hù)的讀取方式?jīng)Q定從哪個(gè)庫(kù)取數(shù)據(jù)。

比如說(shuō)要展示圖表，然后取最近一小時(shí)的數(shù)據(jù)，就直接從 Redis 里面取一小時(shí)，如果取一天的數(shù) 據(jù)，我們就會(huì)做一次降級(jí)，因?yàn)橐环昼姷狞c(diǎn)會(huì)非常密，也是不利于觀察，這時(shí)候我 們會(huì)直接把它降成5分鐘的粒度，從 MongoDB 讀。如果取更久的數(shù)據(jù)，我們就可能依次降級(jí)，做更友好的可視化。

3. 數(shù)據(jù)可視化和報(bào)警

說(shuō)完存儲(chǔ)，我們簡(jiǎn)單說(shuō)一下可視化方面，比較通用的功能就不說(shuō)了，重點(diǎn)說(shuō)一下比較有意思的地方。之前提到我們對(duì)監(jiān)控對(duì)象抽象了一層概念，有 EntityTypes、Entities、Tags。這種情況下可以實(shí)現(xiàn)任意組織架構(gòu)的業(yè)務(wù)視圖組裝。

只需要選擇你要看哪些 EntityTypes，這些 EntityTypes 之間的關(guān)系通過(guò) Tags 描述，然后就可以構(gòu)建出樹(shù)形的組織架構(gòu)，這個(gè)樹(shù)形架構(gòu)就可以直接關(guān)聯(lián)到所有相關(guān) Entities 的數(shù)據(jù)和圖表。

這里有一個(gè)例子，最典型的機(jī)器視圖，有 project，groups、machines，組成一個(gè)三層樹(shù)形結(jié)構(gòu)。

目前我們有 200 多個(gè)自定義視圖，比如這個(gè)機(jī)器視圖，這個(gè)用戶(hù)使用的容器視圖， K8S-Pod-Container的層級(jí)。

這里是監(jiān)控后端的視圖，把 Arbiter-Region-Node 這三個(gè)層級(jí)渲染上去了，然后最下面這一層看到的就是所有 Node 節(jié)點(diǎn)的信息。

同時(shí)如果你想做聚合，不需要上報(bào)多次數(shù)據(jù)，比如這里只需要 Node 報(bào)自己的數(shù)據(jù)，根 據(jù)這個(gè)視圖的組織關(guān)系配一個(gè)向上聚合的規(guī)則，然后前面那個(gè)聚合模塊就會(huì)幫我們搞定所有聚合相關(guān)的事情。這時(shí)候其實(shí)你只要點(diǎn)到 Region 節(jié)點(diǎn)就可以看到所屬 Nodes 總共加起來(lái)有多少數(shù)據(jù)。

我們之前發(fā)現(xiàn)一個(gè)很典型的問(wèn)題，報(bào)警這個(gè)東⻄很難調(diào)試。我們配了一個(gè)規(guī)則，但不知道這個(gè)規(guī)則是否能生效，所以需要造數(shù)據(jù)測(cè)試?；谶@個(gè)痛點(diǎn)，我們迭代新系統(tǒng)的時(shí)候，所有的功能是基于所⻅即所得的原則去做的。

比如說(shuō)這里用戶(hù)給一些 tags，篩選出一批數(shù)據(jù)，這些數(shù)據(jù)就會(huì)直接呈現(xiàn)在圖表，同時(shí)給出一些統(tǒng)計(jì)數(shù)據(jù)，比如說(shuō)均值、percentile。輸入閾值，就會(huì)在圖表顯示出來(lái)閾值和數(shù)據(jù)的相對(duì)關(guān)系，做報(bào)警模板調(diào)試的時(shí)候也是類(lèi)似的，只要選一條已經(jīng)存在的數(shù)據(jù)，就可以按這條數(shù)據(jù)直接按模版渲染報(bào)警出來(lái)。

報(bào)警主要做了如下的策略，首先是指標(biāo)閾值，然后是變化率，還有一些用戶(hù)自定義的異常消息、異常檢測(cè)，還有組合報(bào)警。

用戶(hù)配完這些報(bào)警之后，可以用策略模板分享出來(lái)的。

我們會(huì)有幾百個(gè)項(xiàng)目，有很多運(yùn)維人員在維護(hù)，有些項(xiàng)目可能是同構(gòu)或者說(shuō)是類(lèi)似架構(gòu)的，這種情況報(bào)警策略很多都是相同的，我們可以用策略模板做分享和訂閱，減少人工配置的成本。

再簡(jiǎn)單說(shuō)一下收斂方面做的事情，我們基于整體的規(guī)則引擎處理數(shù)據(jù)，產(chǎn)生問(wèn)題， 后面有一些問(wèn)題合并模塊做合并，目的是盡可能減少報(bào)警。

在合并策略上做了一些人工策略，比如說(shuō)我們可以選擇做一個(gè)十秒鐘的合并，相當(dāng)于做了一定報(bào)警時(shí)效性，同時(shí)增加報(bào)警的準(zhǔn)確性。另一方面我們也會(huì)根據(jù)項(xiàng)目、分類(lèi)、策略等維度做報(bào)警合并。

除此之外，與CMDB關(guān)聯(lián)可以做到更多合并策略，例如CMDB能夠描述網(wǎng) 段和機(jī)器的關(guān)系，就可以做到網(wǎng)絡(luò)層到機(jī)器層到的合并。

問(wèn)題產(chǎn)生之后，我們做了一個(gè)策略確保問(wèn)題會(huì)被及時(shí)處理。產(chǎn)生新問(wèn)題之后，首先 通知值班，有各種方式，比如泡泡、郵件、電話(huà)、短信之類(lèi)。

如果這個(gè)值班正好手機(jī)不在旁邊，確認(rèn)超時(shí)，就會(huì)通知到下一個(gè)backup值班，后面還有2級(jí)值班，3級(jí)值班，如果都沒(méi)有通知到，再回來(lái)通知，這樣一個(gè)方式確保了報(bào)警的可達(dá)性。

這個(gè)過(guò)程只要有任意一個(gè)人收到消息點(diǎn)擊處理問(wèn)題，報(bào)警就被抑制了。對(duì)于一些指標(biāo)類(lèi)的 報(bào)警，我們也做了一個(gè)指標(biāo)恢復(fù)正常時(shí)自動(dòng)關(guān)閉問(wèn)題的邏輯。

4. 智能監(jiān)控實(shí)踐

說(shuō)完報(bào)警相關(guān)的事情，再說(shuō)一下我們?cè)僦悄鼙O(jiān)控方面的一些嘗試。

首先，傳統(tǒng)的報(bào)警中，像閾值、同環(huán)比用的都比較多，能解決很多問(wèn)題，還是有一些情況是沒(méi)辦法覆蓋的。異常檢測(cè)能做到很多事情，一方面能夠按照數(shù)據(jù)的特征去找出異常點(diǎn)。另一方面能夠增量學(xué)習(xí)，適配數(shù)據(jù)變化。

比如說(shuō)，以前某個(gè)數(shù)據(jù)維持在一個(gè)基線(xiàn)上面，如果我們用閾值，有一天這個(gè)數(shù)據(jù)明顯偏離了基線(xiàn)，然后又⻓期穩(wěn)定下來(lái)的，就需要調(diào)閾值。而很多異常檢測(cè)模型可以通過(guò)線(xiàn)上的增量學(xué)習(xí)更新模型適應(yīng)變化。

我們整體流程大概是這樣的，首先是數(shù)據(jù)的抽取、存儲(chǔ)還有標(biāo)注，接下來(lái)做一系列的預(yù)處理，比如對(duì)于非對(duì)稱(chēng)的樣本做重采樣，一些標(biāo)準(zhǔn)化的脫敏等。我們?cè)谔卣鞴こ谭矫孀隽诵U多的努力，目前我們線(xiàn)上比較有價(jià)值的特征大概360多個(gè)。

接下來(lái)是模型訓(xùn)練的流程，我們線(xiàn)上已經(jīng)有一些無(wú)監(jiān)督和有監(jiān)督的模型在跑，也做 了一些集成，同時(shí)這里會(huì)有一個(gè)模型實(shí)時(shí)評(píng)估反饋。模型訓(xùn)練完之后就會(huì)丟到S3的 存儲(chǔ)上，有一套線(xiàn)上實(shí)時(shí)檢測(cè)流，訂閱模型的變更，拉取模型，訂閱數(shù)據(jù)做檢測(cè)和報(bào)警。

我們這邊嘗試過(guò)一些模型。

首先說(shuō)說(shuō)最傳統(tǒng)的統(tǒng)計(jì)學(xué)基于距離、密度等的方法，這些方法有一個(gè)共同特點(diǎn)，使用特別簡(jiǎn)單，不需要標(biāo)注，但是有一個(gè)問(wèn)題就是效果隨緣，它們?cè)谝恍﹫?chǎng)景下表現(xiàn)的很好，另一些場(chǎng)景下，數(shù)據(jù)特點(diǎn)不同，表現(xiàn)的就很差。

第二個(gè)階段我們嘗試 IsolationForest ，這個(gè)算法是我們⻅過(guò)無(wú)監(jiān)督算法里面最好的 一個(gè)，它的 Baseline 相當(dāng)高，在大部分場(chǎng)景下能得到比較好的效果，基本上不用太多調(diào)試。但也有另外一個(gè)問(wèn)題，上限一般，畢竟無(wú)監(jiān)督，沒(méi)有標(biāo)注介入，事實(shí)上很難按你的意圖區(qū)分很多細(xì)節(jié)情況，比有監(jiān)督來(lái)說(shuō)還是有差距。

最后還是走有監(jiān)督的路子，一開(kāi)始嘗試了LSTM、DNN等模型，后續(xù)后是回歸到比較基礎(chǔ)的樹(shù)模型，當(dāng)然也有嘗試做集成，目前集成模型效果會(huì)更好一些。

接下來(lái)我們發(fā)現(xiàn)一個(gè)問(wèn)題，就是在更新樣本集和特征的時(shí)候，會(huì)發(fā)現(xiàn)當(dāng)我們想要滿(mǎn)足一個(gè)場(chǎng)景，就有可能會(huì)對(duì)其他的場(chǎng)景造成誤導(dǎo)。

比如說(shuō)有一些業(yè)務(wù)的曲線(xiàn)本身抖動(dòng)比較厲害，它需要對(duì)大幅度抖動(dòng)進(jìn)行報(bào)警，如果我們把這類(lèi)樣本直接導(dǎo)入樣本集，就可能影響比較平滑的曲線(xiàn)檢測(cè)。當(dāng)然有人說(shuō)我們可以對(duì)前面曲線(xiàn)做平滑，再進(jìn)模型，但這樣的話(huà)其實(shí)會(huì)降低抖動(dòng)幅度比較厲害的曲線(xiàn)的峰值，也會(huì)影響到結(jié)果。

所以這種情況下我們就嘗試做一個(gè)曲線(xiàn)分類(lèi)，抽取一些曲線(xiàn)特征，比如說(shuō)自相關(guān)系數(shù)，比如 說(shuō)抖動(dòng)幅度相關(guān)的特征，用這些特征來(lái)做一下數(shù)據(jù)分類(lèi)，根據(jù)不同的分類(lèi)來(lái)預(yù)訓(xùn)練 模型，嘗試解決這個(gè)問(wèn)題，這樣在某一個(gè)場(chǎng)景下我們加入樣本就不會(huì)影響到另外一個(gè)場(chǎng)景的模型。

簡(jiǎn)單說(shuō)一下我們的模型，預(yù)處理后有features展開(kāi)，然后用xgb做了特征選擇，然后 有SVM、RF、GBDT等一系列的弱模型，最后用LR做一個(gè)簡(jiǎn)單的ensemble。這套模 型在我們的十萬(wàn)條曲線(xiàn)上測(cè)試的結(jié)果大概是85%的precision，因?yàn)槲覀兪侵攸c(diǎn)對(duì) precision做優(yōu)化的，recall會(huì)稍低一些。

說(shuō)完異常檢測(cè)說(shuō)說(shuō)另一個(gè)話(huà)題，我們?cè)趪L試去尋找問(wèn)題之間的關(guān)系，引入了關(guān)聯(lián)分 析。這里的關(guān)聯(lián)分析主要是指時(shí)間序列的關(guān)聯(lián)分析，我們的目標(biāo)是從幾百條曲線(xiàn)中 定位出故障原因或者確定故障影響范圍，或者確定影響整體指標(biāo)的局部指標(biāo)。

整體流程是：從報(bào)警觸發(fā)，通過(guò)CMDB的業(yè)務(wù)配置和一些策略，確定要搜索哪些曲線(xiàn)，然后獲取數(shù)據(jù)，跟當(dāng)前發(fā)生報(bào)警這條曲線(xiàn)做相關(guān)性計(jì)算，最后按相關(guān)性排名， 推送用戶(hù)，用戶(hù)這時(shí)候也會(huì)有一些反饋，我們拿回來(lái)之后做相應(yīng)優(yōu)化。

這是一個(gè)簡(jiǎn)單的模型介紹，一開(kāi)始我們嘗試了一些曲線(xiàn)相似性計(jì)算的模型，一直沒(méi)有取得很好的效果。

后來(lái)我們看到一篇論文，它的觀點(diǎn)很有意思，不去搜索兩個(gè)曲線(xiàn)之間的關(guān)系，只搜索一個(gè)事件和曲線(xiàn)之間的關(guān)系。

因?yàn)槲覀冎狼懊娴那€(xiàn)已經(jīng)有問(wèn)題，我們按這個(gè)時(shí)間節(jié)點(diǎn)，對(duì)需要搜索的曲線(xiàn)前后劃分子序列，抽出兩個(gè)子序列出來(lái)，再到這條曲線(xiàn)上隨機(jī)取一個(gè)子序列，再對(duì)比這三個(gè)子序列之間是不是相同，如果前面的子序列和隨機(jī)子序列不同，我們認(rèn)為這個(gè)序列的變更導(dǎo)致這個(gè)事件，如果是隨機(jī)子序列跟后面那個(gè)子序列不同，我們就認(rèn)為是這個(gè)事件導(dǎo)致這個(gè)序 列的變更，這樣就可以大致構(gòu)建出曲線(xiàn)之間影響的鏈條，形成一個(gè)傳播鏈。

這里面有一定的偶然性，隨機(jī)子序列的選擇非常影響模型的效果，我們也嘗試隨機(jī)多次選擇，合并結(jié)果的方式，去降低它的偶然性。

整體而言，這個(gè)模型在測(cè)試效果中比直接計(jì)算曲線(xiàn)相關(guān)性要好不少。

我今天分享差不多到這里結(jié)束，謝謝。