5個系統管理員常用的警報和視覺化工具
這些開源工具幫助使用者瞭解系統行為和輸出，併為潛在問題提供警報。
你可能使用警報和視覺化工具，為什麼我要將它們作為可觀察性工具進行討論，特別是某些系統將視覺化作為特徵？
可觀察性來自控制理論，描述了我們根據其輸入和輸出理解系統的能力。本文重點介紹可觀察性的輸出元件。
警報和視覺化工具分析系統的輸出，並提供這些輸出的結構化表示。警報基本上是對負系統輸出的綜合理解，並且視覺化是消除使用者理解的消歧結構化表示。
一、常見警報和視覺化 型別
警報
讓我們首先介紹哪些不是警報。 如果人員響應者無法對問題採取任何措施，則不應傳送警報。 這包括髮送給多個人的警報，只有少數人可以響應，或者系統中的每個異常都觸發警報的情況。這導致警報疲勞並且接收器忽略特定介質內的所有警報，直到系統升級到尚未飽和的介質。
例如，如果運維每天從警報系統接收數百封電子郵件，該運維將很快忽略來自警報系統的所有電子郵件。只有當他或她遇到問題，由客戶傳送電子郵件或由老闆打電話時，運維才會回覆真實事件。在這種情況下，警報已失去其意義和用途。
警報不是一個恆定的資訊流或狀態更新。它們旨在傳達系統無法自動恢復的問題，並且它們僅傳送給最有可能恢復系統的個人。超出此定義的所有內容都不是警報，只會損害員工和公司文化。
每個人都有一組不同的警報型別，因此我不會討論優先順序（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不再在內部使用此工具，並表示不再主動維護，但它仍會定期更新。我在這裡強調它主要是指出一個有趣的視覺化機制以及它如何幫助解決問題。值得在演示環境中執行它，以便更好地掌握概念並見證這些系統的可能性。
原文連結：https://opensource.com/article/18/10/alerting-and-visualization-tools-sysadmins
宣告：本文來自安全內參，版權歸作者所有。文章內容僅代表作者獨立觀點，不代表安全內參立場，轉載目的在於傳遞更多資訊。如需轉載，請聯絡原作者獲取授權。