這些開源工具幫助用戶了解系統行為和輸出，并為潛在問題提供警報。

你可能使用警報和可視化工具，為什么我要將它們作為可觀察性工具進行討論，特別是某些系統將可視化作為特征?

可觀察性來自控制理論，描述了我們根據其輸入和輸出理解系統的能力。本文重點介紹可觀察性的輸出組件。

警報和可視化工具分析系統的輸出，并提供這些輸出的結構化表示。警報基本上是對負系統輸出的綜合理解，并且可視化是消除用戶理解的消歧結構化表示。

[[246297]]

一、常見警報和可視化類型

警報

讓我們首先介紹哪些不是警報。如果人員響應者無法對問題采取任何措施，則不應發送警報。這包括發送給多個人的警報，只有少數人可以響應，或者系統中的每個異常都觸發警報的情況。這導致警報疲勞并且接收器忽略特定介質內的所有警報，直到系統升級到尚未飽和的介質。

例如，如果運維每天從警報系統接收數百封電子郵件，該運維將很快忽略來自警報系統的所有電子郵件。只有當他或她遇到問題，由客戶發送電子郵件或由老板打電話時，運維才會回復真實事件。在這種情況下，警報已失去其意義和用途。

警報不是一個恒定的信息流或狀態更新。它們旨在傳達系統無法自動恢復的問題，并且它們僅發送給最有可能恢復系統的個人。超出此定義的所有內容都不是警報，只會損害員工和公司文化。

每個人都有一組不同的警報類型，因此我不會討論優先級(P1-P5)或使用“信息”，“警告”和“嚴重”等字樣的模型。相反，我將描述復雜系統事件響應中出現的通用類別。

你可能已經注意到我提到了一個“信息”警報類型，警報不應該是信息性的。嗯，不是每個人都同意，但如果沒有發送給任何人，我不會認為是警報。它是許多系統稱為警報的數據點。它代表了一些應該知道但沒有響應的事件。它通常是警報工具的可視化系統的一部分，而不是觸發實際通知的事件。Mike Julian在他的“實用監控”一書中介紹了警報的這一方面和其他方面。這是該領域工作的必讀書。

非信息警報由可以響應或需要操作的類型組成。我將這些分為兩類：內部中斷和外部中斷。(大多數公司都有兩個以上的級別來確定其響應工作的優先級。)由于對每個用戶的影響通常是未知的，因此系統性能下降被認為是此模型的中斷。

內部中斷的優先級低于外部中斷，但仍需要快速響應。它們通常包括公司員工使用的內部系統或僅對公司員工可見的應用程序組件。

外部中斷包括任何會立即影響客戶的系統中斷。這些不包括阻止釋放系統更新的系統中斷。它們確實包括面向客戶的應用程序故障，數據庫中斷和網絡分區，如果這兩者都可能影響用戶，則會損害可用性或一致性。它們還包括可能不會對用戶產生直接影響的工具中斷，因為應用程序繼續運行，但這種透明的依賴性會影響性能。這在系統使用某些外部服務或數據源時很常見，這些服務或數據源對于完整功能不是必需的，但是當應用程序執行重試或處理來自此外部依賴項的錯誤時可能會導致延遲。

可視化

有許多可視化類型，我不會在這里全部介紹它們。這是一個迷人的研究領域。在我職業生涯的數據分析方面，學習和應用這些知識是一項持續的挑戰。我們需要提供復雜系統輸出的簡單表示，以便最廣泛地傳播信息。Google Charts和Tableau提供了多種可視化類型。我們將介紹最常見的可視化和一些創新解決方案，以便快速了解系統。

折線圖

折線圖可能是最常見的可視化方式。隨著時間的推移，它可以很好地理解系統。度量系統中的折線圖將為每個唯一度量標準或某些度量標準聚合提供一條線。當同一個儀表板中存在大量指標時，這會讓人感到困惑(如下圖所示)，但大多數系統可以選擇要查看的特定指標，而不是讓所有指標都可見。此外，如果異常行為足以逃避正常操作的噪音，則很容易發現異常行為。下面我們可以看到可能表示異常行為的紫色，黃色和淺藍色線條 

折線圖的另一個特征是可以經常堆疊它們以顯示關系。例如，可能希望單獨查看每個服務器上的請求，但也可以聚合查看。 這使你可以了解整個系統以及同一圖表中的每個實例。

熱力圖

另一種常見的可視化是熱力圖。在查看直方圖時很有用。此類可視化類似于條形圖，但可以在條形圖中顯示表示整體度量標準的不同百分位數的漸變。例如，假設正在查看請求延遲，并且希望快速了解所有請求的總體趨勢和分布。 熱力圖對此非常有用，它可以使用顏色快速瀏覽每個部分的數量。

下面的熱力圖顯示了圖表中心線周圍較高的濃度，每個時間段的垂直分布可以很容易理解。我們可能想要查看分布變寬的幾個時間點，而其他時間點在14:00時相當緊張。此分布可能是負面的績效指標。

壓力表

我將在這里介紹的最后一個常見可視化是儀表，它可以幫助用戶快速了解單個指標。儀表可以代表單個指標，例如車速表代表行駛速度，或者汽油表代表汽車中的汽油量。與燃氣表類似，大多數監控儀表清楚地表明什么是好的，什么不是。 通常(如下圖所示)，好用綠色代表，橙色代表性差，紅色代表“一切都破壞”。 下面的中間一行顯示了傳統的儀表。

此圖像顯示的不僅僅是傳統的儀表。其他儀表是單一的統計表示，類似于經典儀表的功能。它們都使用相同的配色方案，只需一瞥即可快速指示系統健康狀況。可以說，底行可能是衡量儀表的最佳示例，它允許您瀏覽儀表板并知道一切都是健康的(或不是)。這種類型的可視化通常是我放在頂層儀表板上的。它可以在幾秒鐘內全面，高層次地了解系統運行狀況。

火焰圖

不太常見的可視化是由Netflix的Brendan Gregg于2011年推出的火焰圖。它不是儀表板或快速觀察高級系統問題的理想選擇。在嘗試理解特定的應用程序問題時通常會看到它。此可視化關注于CPU和內存以及關聯的幀。 X軸按字母順序列出幀，Y軸顯示堆棧深度。每個矩形都是一個堆棧幀，包括被調用的函數。矩形越寬，它在堆棧中出現的越多。在嘗試在應用程序級別診斷系統性能時，此方法非常有用，我建議大家嘗試一下。

工具選擇

報警有幾種商業選擇，但由于這是Opensource.com，我將僅涵蓋真實公司大規模使用的系統，可以免費使用。希望你能夠貢獻新的和創新的功能，使這些系統更好。

二、警報工具

1.Bosun

如果你曾經使用計算機做過任何事情并且卡住了，那么你收到的幫助可能歸功于Stack Exchange系統。Stack Exchange圍繞眾包問答模型運行許多不同的網站。Stack Overflow非常受開發人員歡迎，超級用戶很受操作的歡迎。然而，現在有數百個網站，從育兒到科幻，哲學到自行車。

Stack Exchange開源其警報管理系統Bosun，同時Prometheus及其AlertManager系統也已發布。這兩個系統有許多相似之處，這是一件非常好的事情。像Prometheus一樣，Bosun是用Golang寫的。Bosun的范圍比Prometheus更廣泛，因為它可以與指標聚合之外的系統進行交互。它還可以從日志和事件聚合系統中提取數據。它支持Graphite，InfluxDB，OpenTSDB和Elasticsearch。

Bosun的架構由一個服務器二進制文件，一個像OpenTSDB，Redis和scollector代理的后端組成。scollector代理自動檢測主機上的服務，并報告這些進程和其他系統資源的度量標準。此數據將發送到指標后端。然后，Bosun服務器二進制文件查詢后端以確定是否需要觸發任何警報。 Bosun也可以被像Grafana這樣的工具用來通過一個通用接口查詢底層后端。 Redis用于存儲Bosun的狀態和元數據。

Bosun的一個非常巧妙的功能是它可以根據歷史數據測試警報。這是我幾年前在Prometheus錯過的東西，當時我有一個問題的數據，我想要警報，但沒有簡單的方法來測試它。為了確保我的警報正常，我必須創建并插入虛擬數據。該系統減輕了非常耗時的過程。

Bosun還具有通常的功能，如顯示簡單的圖形和創建警報。它具有強大的表達語言，可用于編寫警報規則。但是，它只有電子郵件和HTTP通知配置，這意味著連接到Slack和其他工具需要更多的自定義(其文檔涵蓋)。與Prometheus類似，Bosun可以使用模板進行這些通知，這意味著它們可以像您希望的那樣看起來很棒。可以使用所有HTML和CSS技能創建任何人見過的最糟糕的電子郵件提醒。

2.Cabot

Cabot是由一家名為Arachnys的公司創建的。你可能不知道Arachnys是誰或它做了什么，但你可能已經感受到它的影響：它構建了領先的基于云的解決金融犯罪的解決方案。這聽起來很酷，對嗎?在以前的公司，我參與了“了解你的客戶”法律的類似職能。大多數公司認為與恐怖組織聯系是一件非常糟糕的事情，例如，通過他們的系統匯集資金。這些解決方案也有助于防范對欺詐者等不那么殘暴的罪犯，也可能對該機構構成風險。

為什么Arachnys創造abot?嗯，這對每個人來說都是一個圣誕禮物，因為這是一個圣誕節項目，因為它的開發人員無法圍繞Nagios。真的，誰可以怪他們? Cabot是用Django和Bootstrap編寫的，因此對大多數人來說應該很容易為項目做出貢獻。 (另一個有趣的事實：名字來自創作者的狗。)

Cabot架構與Bosun類似，因為它不收集任何數據。相反，它通過其提醒的工具的API訪問數據。因此，Cabot使用拉動(而非推動)模型進行警報。它可以訪問每個系統的API，并根據特定的檢查檢索所需的信息。 Cabot將警報數據存儲在Postgres數據庫中，并且還具有使用Redis的緩存。

Cabot原生支持Graphite，但它也支持Jenkins，這在該領域很少見。Arachnys使用Jenkins就像一個集中式的cron，但我喜歡這種處理構建失敗的想法，比如停機。顯然，構建失敗并不像生產中斷那么重要，但如果失敗未得到解決，它仍然可以提醒團隊并升級。每次收到有關構建失敗的電子郵件時，誰真正檢查Jenkins?我也是!

另一個有趣的功能是Cabot可以與Google日歷集成以進行隨叫隨到的輪換。Cabot將此功能稱為羅塔(Rota)，這是英國名單或輪換名詞。這很有意義，我希望其他系統能夠進一步理解這個想法。Cabot不支持比主要和備用人員更復雜的任何東西，但肯定有額外功能的空間。文檔說如果你想要更先進的東西，你應該看一個商業選擇。

3.StatsAgg

StatsAgg?這是怎么做到的?好吧，并不是每天都會遇到一家創建了警報平臺的出版公司。我認為值得認可。當然，皮爾森不再只是一家出版公司了;它有幾個網站和O'Reilly Media的合資企業。但是，我仍然認為它是出版我的教科書和考試的公司。

StatsAgg不僅僅是一個警報平臺;它也是一個指標聚合平臺。它有點像其他系統的代理。它支持Graphite，StatsD，InfluxDB和OpenTSDB作為輸入，但它也可以將這些指標轉發到各自的平臺。這是一個有趣的概念，但隨著中央服務的負載增加，可能存在風險。但是，如果StatsAgg基礎結構足夠強大，即使后端存儲平臺出現中斷，它仍然可以生成警報。

StatsAgg是用Java編寫的，只包含主服務器和UI，可以將復雜性降至最低。它可以基于正則表達式匹配發送警報，并專注于服務而不是主機或實例的警報。 它的目標是填充開源可觀察性堆棧中的空白，我認為它做得很好。

三、可視化工具

1.Grafana

幾乎每個人都知道Grafana，很多人都使用過它。每當我需要一個簡單的儀表板時，我已經使用了它多年。我之前使用過的工具已經棄用了，在Grafana做好之前我對此非常不滿。Grafana被TorkelÖdegaard創建。像Cabot一樣，Grafana也是在圣誕節期間創建的，并于2014年1月發布。在短短幾年內它已經走過了漫長的道路。它起源于Kibana儀表板系統，Torkel將其分為Grafana。

Grafana的唯一重點是以更加實用和令人愉悅的方式呈現監控數據。它可以原生地從Graphite，Elasticsearch，OpenTSDB，Prometheus和InfluxDB收集數據。有一個企業版使用插件來獲取更多數據源，但是沒有理由將這些其他數據源插件創建為開源，因為Grafana插件生態系統已經提供了許多其他數據源。

Grafana為我做了什么?它為理解我的系統提供了一個中心位置。它是基于Web的，因此任何人都可以訪問這些信息，盡管可以使用不同的身份驗證方法對其進行限制。 Grafana可以使用許多不同類型的可視化提供一目了然的知識。但是，它已開始集成警報和其他傳統上與可視化相結合的功能。

現在，你可以直觀地設置警報。這意味著可以查看圖表，甚至可以查看由于系統性能下降而應該觸發警報的位置，單擊要觸發警報的圖表，然后告訴Grafana將警報發送到何處。這是一個非常強大的補充，不一定會取代警報平臺，但它肯定可以通過提供警報標準的不同視角來幫助增強它。

Grafana還引入了更多協作功能。用戶已經能夠長時間共享儀表板，這意味著不必為Kubernetes集群創建自己的儀表板，因為有幾個已經可用，其中一些由Kubernetes開發人員和其他人由Grafana開發人員維護。

協作中最重要的補充是注釋。注釋允許用戶將上下文添加到圖形的一部分。然后，其他用戶可以使用此上下文更好地理解系統。當團隊處于事件中并且溝通和共同理解至關重要時，這是一個非常寶貴的工具。將所有信息都放在你正在查看的位置，這樣可以更快地在整個團隊中共享知識。當團隊試圖了解失敗的原因并了解他們的系統時，這也是一個很好的功能，可用于無可指責的事后。

2.Vizceral

Netflix創建了Vizceral，以便在執行流量故障轉移時更好地了解其流量模式。與Grafana不同，Grafana是一種更通用的工具，Vizceral提供了非常具體的用例。Netflix不再在內部使用此工具，并表示不再主動維護，但它仍會定期更新。我在這里強調它主要是指出一個有趣的可視化機制以及它如何幫助解決問題。值得在演示環境中運行它，以便更好地掌握概念并見證這些系統的可能性。