常見(jiàn)的可視化告警

你大概已經(jīng)知道（或猜到）告警可視化alerting and visualization工具是用來(lái)做什么的了。下面我們就要來(lái)說(shuō)一下，為什么要討論這樣的工具，甚至某些系統(tǒng)專(zhuān)門(mén)將可視化作為特有的功能。

可觀察性O(shè)bservability的概念來(lái)自控制理論control theory，這個(gè)概念描述了我們通過(guò)對(duì)系統(tǒng)的輸入和輸出來(lái)了解其的能力。本文將重點(diǎn)介紹具有可觀察性的輸出組件。

告警可視化工具可以對(duì)其它系統(tǒng)的輸出進(jìn)行分析，進(jìn)而對(duì)輸出的信息進(jìn)行結(jié)構(gòu)化表示。告警實(shí)際上是對(duì)系統(tǒng)異常狀態(tài)的描述，而可視化則是讓用戶能夠直觀理解的結(jié)構(gòu)化表示。

常見(jiàn)的可視化告警

告警

首先要明確一下告警alert的含義。在人員無(wú)法響應(yīng)告警內(nèi)容情況下，不應(yīng)該發(fā)送告警 —— 包括那些發(fā)給多個(gè)人但只有其中少數(shù)人可以響應(yīng)的告警，以及系統(tǒng)中的每個(gè)異常都觸發(fā)的告警。因?yàn)檫@樣會(huì)產(chǎn)生告警疲勞，告警接收者也往往會(huì)對(duì)這些過(guò)多的告警采取忽視的態(tài)度 —— 直到系統(tǒng)惡化到以少見(jiàn)的方式告警。

例如，如果管理員每天都會(huì)收到告警系統(tǒng)發(fā)來(lái)的數(shù)百封告警郵件，他就很容易會(huì)忽略告警系統(tǒng)的所有郵件。除非他真的看到問(wèn)題發(fā)生，或者受到了客戶或上級(jí)的詢問(wèn)時(shí)，管理員才會(huì)重新重視告警信息。在這種情況下，告警已經(jīng)失去了原有的意義和用途。

告警不是一個(gè)持續(xù)的信息流或者狀態(tài)更新。告警的目的在于暴露系統(tǒng)無(wú)法自動(dòng)恢復(fù)的問(wèn)題，而且告警應(yīng)該只發(fā)送給最有可能解決問(wèn)題的人員。超出這個(gè)定義的內(nèi)容都不應(yīng)該作為告警，否則將會(huì)對(duì)實(shí)際工作造成不良的影響。

不同的告警體系都會(huì)有各自的告警類(lèi)型，因此不能用優(yōu)先級(jí)（P1-P5）或者諸如“信息”、“警告”、“嚴(yán)重”之類(lèi)的字眼來(lái)一概而論，下面我會(huì)介紹一些新興的復(fù)雜系統(tǒng)的事件響應(yīng)中出現(xiàn)的通用分類(lèi)方式。

剛才我提到了一個(gè)“信息”這個(gè)告警類(lèi)型，但實(shí)際上告警不應(yīng)該是一個(gè)信息，盡管有些人可能會(huì)不這樣認(rèn)為。但我覺(jué)得如果一個(gè)告警沒(méi)有發(fā)送給任何一個(gè)人，它就不應(yīng)該是警報(bào)，而只是一些在許多系統(tǒng)中被視為警報(bào)的數(shù)據(jù)點(diǎn)，代表了一些應(yīng)該知曉但不需要響應(yīng)的事件。它更應(yīng)該作為告警可視化工具的一部分，而不是會(huì)導(dǎo)致觸發(fā)告警的事件?！秾?shí)用監(jiān)控》是這個(gè)領(lǐng)域的必讀書(shū)籍，其作者 Mike Julian 在書(shū)中就介紹了他自己關(guān)于告警的看法。

而非信息警報(bào)則代表告警需要被響應(yīng)以及需要相關(guān)的操作。我將這些告警大致分為內(nèi)部故障和外部故障兩種類(lèi)型，而對(duì)于大多數(shù)公司來(lái)說(shuō)，通常會(huì)有兩個(gè)以上的級(jí)別來(lái)確定響應(yīng)告警的優(yōu)先級(jí)。系統(tǒng)性能下降就是一種故障，因?yàn)槠鋵?duì)用戶的影響通常都是未知的。

內(nèi)部故障比外部故障的優(yōu)先級(jí)低，但也需要快速響應(yīng)。內(nèi)部故障通常包括公司員工使用的內(nèi)部系統(tǒng)或僅對(duì)公司員工可見(jiàn)的應(yīng)用故障。

外部故障則包括任何馬上會(huì)產(chǎn)生業(yè)務(wù)影響的系統(tǒng)故障，但不包括影響系統(tǒng)更新的故障。外部故障一般包括客戶所面臨的應(yīng)用故障、數(shù)據(jù)庫(kù)故障和導(dǎo)致系統(tǒng)可用性或一致性失效的網(wǎng)絡(luò)故障，這些都會(huì)影響用戶的正常使用。對(duì)于不直接影響用戶的依賴組件故障也屬于外部故障，隨著應(yīng)用程序的不斷運(yùn)行，一旦依賴組件發(fā)生故障，系統(tǒng)的性能也會(huì)受到波及。這種情況對(duì)于使用某些外部服務(wù)或數(shù)據(jù)源的系統(tǒng)來(lái)說(shuō)很常見(jiàn)，盡管這些外部服務(wù)或數(shù)據(jù)源對(duì)于可能不涉及到系統(tǒng)的主要功能，但是當(dāng)系統(tǒng)在處理相關(guān)依賴組件的錯(cuò)誤時(shí)可能會(huì)出現(xiàn)較明顯的延遲。

可視化

可視化的種類(lèi)有很多，我就不一一贅述了。這是一個(gè)有趣的研究領(lǐng)域，在我這些年的數(shù)據(jù)分析經(jīng)歷當(dāng)中，學(xué)習(xí)和應(yīng)用可視化方面的知識(shí)可以說(shuō)是相當(dāng)有挑戰(zhàn)性。我們需要將復(fù)雜的系統(tǒng)輸出通過(guò)直觀的方式來(lái)向他人展示，才能有效地把信息傳播出去。Google Charts和Tableau都提供了很多可視化方面的工具。下面將會(huì)介紹一些最常見(jiàn)的可視化創(chuàng)新解決方案。

折線圖

折線圖可能是最常見(jiàn)的可視化方式了，它可以讓用戶很直觀地按照時(shí)間維度了解系統(tǒng)的情況。系統(tǒng)中每個(gè)單一或聚合的指標(biāo)都會(huì)以一條折線在圖表中體現(xiàn)。但當(dāng)同一個(gè)圖表中同時(shí)存在多條折線時(shí)，就可能會(huì)對(duì)閱讀有所影響（如下圖所示），所以大多數(shù)情況下都可以選擇僅查看其中的少數(shù)幾條折線，而不是讓所有折線同時(shí)顯示。如果某個(gè)指標(biāo)的數(shù)值產(chǎn)生了大于正常范圍的波動(dòng)，就會(huì)很容易發(fā)現(xiàn)。例如下圖中異常的紫線、黃線、淺藍(lán)線。

折線圖的另一個(gè)用法是可以將多條折線堆疊起來(lái)以顯示它們之間的關(guān)系。例如對(duì)于通過(guò)折線圖反映服務(wù)器的請(qǐng)求數(shù)量，可以單獨(dú)看到每臺(tái)服務(wù)器上的請(qǐng)求，也可以聚合在一起看。這就可以在同一個(gè)圖表中靈活查看整個(gè)系統(tǒng)以及每個(gè)實(shí)例的情況了。

熱力圖

另一種常見(jiàn)的可視化方式是熱力圖。熱力圖與條形圖比較類(lèi)似，還可以在條形圖的基礎(chǔ)上顯示某部分在整體中占比的變化情況。例如在查看網(wǎng)絡(luò)請(qǐng)求延時(shí)的時(shí)候，就可以使用熱力圖快速查看到所有網(wǎng)絡(luò)請(qǐng)求的總體趨勢(shì)和分布情況，另外，它可以使用不同顏色來(lái)表示不同部分的數(shù)值。

在以下這個(gè)熱力圖中，通過(guò)豎直方向上每個(gè)時(shí)間段的色塊數(shù)量分布，可以清楚地看到大部分?jǐn)?shù)據(jù)集中在整個(gè)范圍的中心位置。我們還可以發(fā)現(xiàn)，大多數(shù)時(shí)間段的色塊分布都是比較寬松的，而 14:00 到 15:00 這一段則分布得很密集，這樣的分布有可能意味著一種不健康的狀態(tài)。

儀表圖

還有一種常見(jiàn)的可視化方式是儀表圖，用戶可以通過(guò)儀表圖快速了解單個(gè)指標(biāo)。儀表一般用于單個(gè)指標(biāo)的顯示，例如車(chē)速表代表汽車(chē)的行駛速度、油量表代表油箱中的汽油量等等。大多數(shù)的儀表圖都有一個(gè)共通點(diǎn)，就是會(huì)劃分出所示指標(biāo)的對(duì)應(yīng)狀態(tài)。如下圖所示，綠色表示正常的狀態(tài)，橙色表示不良的狀態(tài)，而紅色則表示極差的狀態(tài)。下圖中間一行模擬了真實(shí)儀表的顯示情況。

上面圖表中，除了常規(guī)儀表樣式的顯示方式之外，還有較為直接的數(shù)據(jù)顯示方式，配合相同的配色方案，一眼就可以看出各個(gè)指標(biāo)所處的狀態(tài)，這一點(diǎn)與和儀表的特點(diǎn)類(lèi)似。所以，最下面一行可能是儀表圖的最佳顯示方式，用戶不需要仔細(xì)閱讀，就可以大致了解各個(gè)指標(biāo)的不同狀態(tài)。這種類(lèi)型的可視化是我最常用的類(lèi)型，在數(shù)秒鐘之間，我就可以全面地總覽系統(tǒng)各方面地運(yùn)行情況。

火焰圖

由Netflix 的 Brendan Gregg在 2011 年開(kāi)始使用的火焰圖是一種較為少見(jiàn)地可視化方式。它不像儀表圖那樣可以從圖表中快速得到關(guān)鍵信息，通常只會(huì)在需要解決某個(gè)應(yīng)用的問(wèn)題的時(shí)候才會(huì)用到這種圖表。火焰圖主要用于 CPU、內(nèi)存和相關(guān)幀方面的表示，X 軸按字母順序?qū)灰涣谐?，?Y 軸則表示堆棧的深度。圖中每個(gè)矩形都是一個(gè)標(biāo)明了調(diào)用的函數(shù)的堆棧幀。矩形越寬，就表示它在堆棧中出現(xiàn)越頻繁。在分析系統(tǒng)性能問(wèn)題的時(shí)候，火焰圖能夠起到很大的作用，大家不妨嘗試一下。

工具的選擇

在告警工具方面，有幾個(gè)商用的工具相當(dāng)不錯(cuò)。但由于這是一篇介紹開(kāi)源技術(shù)的文章，我只會(huì)介紹那些已經(jīng)被廣泛使用的免費(fèi)工具。希望你也能夠?yàn)檫@些工具貢獻(xiàn)你自己的代碼，讓它們更加完善。

告警工具

Bosun

如果你的電腦出現(xiàn)問(wèn)題，得多虧 Stack Exchange 你才能在網(wǎng)上查到解決辦法。Stack Exchange 以眾包問(wèn)答的模式運(yùn)營(yíng)著很多不同類(lèi)型的網(wǎng)站。其中就有廣受開(kāi)發(fā)者歡迎的Stack Overflow，以及運(yùn)維方面有名的Super User。除此以外，從育兒經(jīng)驗(yàn)到科幻小說(shuō)、從哲學(xué)討論到單車(chē)論壇，Stack Exchange 都有涉獵。

Stack Exchange 開(kāi)源了它的告警管理系統(tǒng)Bosun，同時(shí)也發(fā)布了 Prometheus 及其AlertManager系統(tǒng)。這兩個(gè)系統(tǒng)有共通點(diǎn)。Bosun 和 Prometheus 一樣使用 Golang 開(kāi)發(fā)，但 Bosun 比 Prometheus 更為強(qiáng)大，因?yàn)樗梢允褂弥笜?biāo)聚合metrics aggregation以外的方式與系統(tǒng)交互。Bosun 還可以從日志和事件收集系統(tǒng)中提取數(shù)據(jù)，并且支持 Graphite、InfluxDB、OpenTSDB 和 Elasticsearch。

Bosun 的架構(gòu)包括一個(gè)單一的服務(wù)器的二進(jìn)制文件，一個(gè)諸如 OpenTSDB 的后端、Redis 以及scollector 代理。 scollector 代理會(huì)自動(dòng)檢測(cè)主機(jī)上正在運(yùn)行的服務(wù)，并反饋這些進(jìn)程和其它的系統(tǒng)資源的情況。這些數(shù)據(jù)將發(fā)送到后端。隨后 Bosun 的二進(jìn)制服務(wù)文件會(huì)向后端發(fā)起查詢，確定是否需要觸發(fā)告警。也可以通過(guò)Grafana這些工具通過(guò)一個(gè)通用接口查詢 Bosun 的底層后端。而 Redis 則用于存儲(chǔ) Bosun 的狀態(tài)信息和元數(shù)據(jù)。

Bosun 有一個(gè)非常巧妙的功能，就是可以根據(jù)歷史數(shù)據(jù)來(lái)測(cè)試告警。這是我?guī)啄昵霸谑褂?Prometheus 的時(shí)候就非常需要的功能，當(dāng)時(shí)我有一個(gè)異常的數(shù)據(jù)需要產(chǎn)生告警，但沒(méi)有一個(gè)可以用于測(cè)試的簡(jiǎn)便方法。為了確保告警能夠正常觸發(fā)，我不得不造出對(duì)應(yīng)的數(shù)據(jù)來(lái)進(jìn)行測(cè)試。而 Bosun 讓這個(gè)步驟的耗時(shí)大大縮短。

Bosun 更是涵蓋了所有常用過(guò)的功能，包括簡(jiǎn)單的圖形化表示和告警的創(chuàng)建。它還帶有強(qiáng)大的用于編寫(xiě)告警規(guī)則的表達(dá)式語(yǔ)言。但 Bosun 默認(rèn)只帶有電子郵件通知配置和 HTTP 通知配置，因此如果需要連接到 Slack 或其它工具，就需要對(duì)配置作出更大程度的定制化（其文檔中有）。類(lèi)似于 Prometheus，Bosun 還可以使用模板通知，你可以使用 HTML 和 CSS 來(lái)創(chuàng)建你所需要的電子郵件通知。

Cabot

Cabot由Arachnys公司開(kāi)發(fā)。你或許對(duì) Arachnys 公司并不了解，但它很有影響力：Arachnys 公司構(gòu)建了一個(gè)基于云的先進(jìn)解決方案，用于防范金融犯罪。在之前的公司時(shí)，我也曾經(jīng)參與過(guò)類(lèi)似“了解你的客戶（KYC）”的工作。大多數(shù)公司都認(rèn)為與恐怖組織產(chǎn)生聯(lián)系會(huì)造成相當(dāng)不好的影響，因?yàn)榭植澜M織可能會(huì)利用自己的系統(tǒng)來(lái)籌集資金。而這些解決方案將有助于防范欺詐類(lèi)犯罪，盡管這類(lèi)犯罪情節(jié)相對(duì)較輕，但仍然也會(huì)對(duì)機(jī)構(gòu)產(chǎn)生風(fēng)險(xiǎn)。

Arachnys 公司為什么要開(kāi)發(fā) Cabot 呢？其實(shí)只是因?yàn)?Arachnys 的開(kāi)發(fā)人員對(duì)Nagios不太熟悉。Cabot 的出現(xiàn)對(duì)很多人來(lái)說(shuō)都是一個(gè)好消息，它基于 Django 和 Bootstrap 開(kāi)發(fā)，因此如果想對(duì)這個(gè)項(xiàng)目做出自己的貢獻(xiàn)，門(mén)檻并不高。（另外值得一提的是，Cabot 這個(gè)名字來(lái)源于開(kāi)發(fā)者的狗。）

與 Bosun 類(lèi)似，Cabot 也不對(duì)數(shù)據(jù)進(jìn)行收集，而是使用監(jiān)控對(duì)象的 API 提供的數(shù)據(jù)。因此，Cabot 告警的模式是拉取而不是推送。它通過(guò)訪問(wèn)每個(gè)監(jiān)控對(duì)象的 API，根據(jù)特定的指標(biāo)檢索所需的數(shù)據(jù)，然后將告警數(shù)據(jù)使用 Redis 緩存，進(jìn)而持久化存儲(chǔ)到 Postgres 數(shù)據(jù)庫(kù)。

Cabot 的一個(gè)較為少見(jiàn)的特點(diǎn)是，它原生支持Graphite，同時(shí)也支持Jenkins。Jenkins 在這里被視為一個(gè)集中式的定時(shí)任務(wù)，它會(huì)以對(duì)待故障的方式去對(duì)待構(gòu)建失敗的狀況。構(gòu)建失敗當(dāng)然沒(méi)有系統(tǒng)故障那么緊急，但一旦出現(xiàn)構(gòu)建失敗，還是需要團(tuán)隊(duì)采取措施去處理，畢竟并不是每個(gè)人在收到構(gòu)建失敗的電子郵件時(shí)都會(huì)親自去檢查 Jenkins。

Cabot 另一個(gè)有趣的功能是它可以接入 Google 日歷安排值班人員，這個(gè)稱為 Rota 的功能用處很大，希望其它告警系統(tǒng)也能加入類(lèi)似的功能。Cabot 目前僅支持安排主備聯(lián)系人，但還有繼續(xù)改進(jìn)的空間。它自己的文檔也提到，如果需要全面的功能，更應(yīng)該考慮付費(fèi)的解決方案。

StatsAgg

Pearson作為一家開(kāi)發(fā)了StatsAgg告警平臺(tái)的出版公司，這是極為罕見(jiàn)的，當(dāng)然也很值得敬佩。除此以外，Pearson 還運(yùn)營(yíng)著另外幾個(gè)網(wǎng)站以及和O’Reilly Media合資的企業(yè)。但我仍然會(huì)將它視為出版教學(xué)書(shū)籍的公司。

StatsAgg 除了是一個(gè)告警平臺(tái)，還是一個(gè)指標(biāo)聚合平臺(tái)，甚至也有點(diǎn)類(lèi)似其它系統(tǒng)的代理。StatsAgg 支持通過(guò) Graphite、StatsD、InfluxDB 和 OpenTSDB 輸入數(shù)據(jù)，也支持將其轉(zhuǎn)發(fā)到各種平臺(tái)。但隨著中心服務(wù)的負(fù)載不斷增加，風(fēng)險(xiǎn)也不斷增大。盡管如此，如果 StatsAgg 的基礎(chǔ)架構(gòu)足夠強(qiáng)壯，即使后端存儲(chǔ)平臺(tái)出現(xiàn)故障，也不會(huì)對(duì)它產(chǎn)生告警的過(guò)程造成影響。

StatsAgg 是用 Java 開(kāi)發(fā)的，為了盡可能降低復(fù)雜性，它僅包括主服務(wù)和一個(gè) UI。StatsAgg 支持基于正則表達(dá)式匹配來(lái)發(fā)送告警，而且它更注重于服務(wù)方面的告警，而不是服務(wù)器基礎(chǔ)告警。我認(rèn)為它填補(bǔ)了開(kāi)源監(jiān)控工具方面的空白，而這正式它自己的目標(biāo)。

可視化工具

Grafana

Grafana的知名度很高，它也被廣泛采用。每當(dāng)我需要用到數(shù)據(jù)面板的時(shí)候，我總是會(huì)想到它，因?yàn)樗任沂褂眠^(guò)的任何一款類(lèi)似的產(chǎn)品都要好。Grafana 由 Torkel ?degaard 開(kāi)發(fā)的，像 Cabot 一樣，也是在圣誕節(jié)期間開(kāi)發(fā)的，并在 2014 年 1 月發(fā)布。在短短幾年之間，它已經(jīng)有了長(zhǎng)足的發(fā)展。Grafana 基于 Kibana 開(kāi)發(fā)，Torkel 開(kāi)啟了新的分支并將其命名為 Grafana。

Grafana 著重體現(xiàn)了實(shí)用性以及數(shù)據(jù)呈現(xiàn)的美觀性。它天生就可以從 Graphite、Elasticsearch、OpenTSDB、Prometheus 和 InfluxDB 收集數(shù)據(jù)。此外有一個(gè) Grafana 商用版插件可以從更多數(shù)據(jù)源獲取數(shù)據(jù)，但是其他數(shù)據(jù)源插件也并非沒(méi)有開(kāi)源版本，Grafana 的插件生態(tài)系統(tǒng)已經(jīng)提供了各種數(shù)據(jù)源。

Grafana 能做什么呢？Grafana 提供了一個(gè)中心化的了解系統(tǒng)的方式。它通過(guò) web 來(lái)展示數(shù)據(jù)，任何人都有機(jī)會(huì)訪問(wèn)到相關(guān)信息，當(dāng)然也可以使用身份驗(yàn)證來(lái)對(duì)訪問(wèn)進(jìn)行限制。Grafana 使用各種可視化方式來(lái)提供對(duì)系統(tǒng)一目了然的了解。Grafana 還支持不同類(lèi)型的可視化方式，包括集成告警可視化的功能。

現(xiàn)在你可以更直觀地設(shè)置告警了。通過(guò) Grafana，可以查看圖表，還可以查看由于系統(tǒng)性能下降而觸發(fā)告警的位置，單擊要觸發(fā)報(bào)警的位置，并告訴 Grafana 將告警發(fā)送何處。這是一個(gè)對(duì)告警平臺(tái)非常強(qiáng)大的補(bǔ)充。告警平臺(tái)不一定會(huì)因此而被取代，但告警系統(tǒng)一定會(huì)由此得到更多啟發(fā)和發(fā)展。

Grafana 還引入了很多團(tuán)隊(duì)協(xié)作的功能。不同用戶之間能夠共享數(shù)據(jù)面板，你不再需要為Kubernetes集群創(chuàng)建獨(dú)立的數(shù)據(jù)面板，因?yàn)橛?Kubernetes 開(kāi)發(fā)者和 Grafana 開(kāi)發(fā)者共同維護(hù)的一些數(shù)據(jù)面板已經(jīng)可用了。

團(tuán)隊(duì)協(xié)作過(guò)程中一個(gè)重要的功能是注釋。注釋功能允許用戶將上下文添加到圖表當(dāng)中，其他用戶就可以通過(guò)上下文更直觀地理解圖表。當(dāng)團(tuán)隊(duì)成員在處理某個(gè)事件，并且需要溝通和理解時(shí)，這個(gè)功能就十分重要了。將所有相關(guān)信息都放在需要的位置，可以讓整個(gè)團(tuán)隊(duì)中快速達(dá)成共識(shí)。在團(tuán)隊(duì)需要調(diào)查故障原因和定位事件責(zé)任時(shí)，這個(gè)功能就可以發(fā)揮作用了。

Vizceral

Vizceral由 Netflix 開(kāi)發(fā)，用于在故障發(fā)生時(shí)更有效地了解流量的情況。Grafana 是一種通用性更強(qiáng)的工具，而 Vizceral 則專(zhuān)用于某些領(lǐng)域。 盡管 Netflix 表示已經(jīng)不再在內(nèi)部使用 Vizceral，也不再主動(dòng)對(duì)其展開(kāi)維護(hù)，但 Vizceral 仍然會(huì)定期更新。我在這里介紹這個(gè)工具，主要是為了介紹它的的可視化機(jī)制，以及如何利用它來(lái)協(xié)助解決問(wèn)題。你可以在樣例環(huán)境中用它來(lái)更好地掌握這一類(lèi)系統(tǒng)的特性。