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

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

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

常見的可視化告警

告警

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

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

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

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

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

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

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

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

可視化

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

折線圖

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

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

熱力圖

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

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

儀表圖

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

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

火焰圖

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

工具的選擇

在告警工具方面，有幾個商用的工具相當不錯。但由于這是一篇介紹開源技術(shù)的文章，我只會介紹那些已經(jīng)被廣泛使用的免費工具。希望你也能夠為這些工具貢獻你自己的代碼，讓它們更加完善。

告警工具

Bosun

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

Stack Exchange 開源了它的告警管理系統(tǒng)Bosun，同時也發(fā)布了 Prometheus 及其AlertManager系統(tǒng)。這兩個系統(tǒng)有共通點。Bosun 和 Prometheus 一樣使用 Golang 開發(fā)，但 Bosun 比 Prometheus 更為強大，因為它可以使用指標聚合metrics aggregation以外的方式與系統(tǒng)交互。Bosun 還可以從日志和事件收集系統(tǒng)中提取數(shù)據(jù)，并且支持 Graphite、InfluxDB、OpenTSDB 和 Elasticsearch。

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

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

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

Cabot

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

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

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

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

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

StatsAgg

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

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

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

可視化工具

Grafana

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

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

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

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

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

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

Vizceral

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