一些好用的開源監控工具彙總
監控系統是整個 IT 架構中的重中之重，小到故障排查、問題定位，大到業務預測、運營管理，都離不開監控系統，可以說一個穩定、健康的 IT 架構中必然會有一個可信賴的監控系統。
但是，難道監控就只是監控？多年來，對於監控的術語一直都有很多困惑，一些很糟糕的工具也宣稱能夠以一種格式完成所有事情。
在 DevOps 和雲原生時代，今年，“可觀察性”（Observability）被引入到了 IT 領域，其首先表現為 CNCF-Landscape 出現了 Observability 分組。從該分組的內容看包含了監控，日誌，Tracing 等領域的專案。可觀察性與監控有什麼不同？簡單說來，後者是前者的一個子集。監控關注系統的失敗因素，從而定義出系統的失敗模型。它的核心是運維，是監控設施。而可觀察性除了關注失敗之外，其核心是研發，是應用，是對系統的一種自我審視。是站在創造者的角度去探究系統應如何恰當的展現自身的狀態。一個由外向內，一個由內向外。
觀察工具包括：度量聚合（Metrics aggregation）（主要是時序資料），日誌聚合（Log aggregation），告警／視覺化（Alerting/visualizations），分散式追蹤（Distributed tracing）。
監控工具Prometheus 是雲原生應用程式最受認可的時間序列監控解決方案，由 CNCF 託管，使用 Go 語言開發，是 Google BorgMon 監控系統的類似實現。
Prometheus 使用的是 Pull 模型，Prometheus Server 通過 HTTP 的 pull 方式到各個目標拉取監控資料。它使用區域性配置來描述要收集的端點和收集所需的間隔。 每個端點都有一個客戶端收集資料並在每次請求時更新該表示（或者客戶端是配置的）。 收集此資料並將其儲存在本地磁碟上的高效儲存引擎中。 儲存系統使用每個度量標準的僅附加檔案。
Prometheus 包含一種高階表示式語言，用於選擇和顯示名為 PromQL 的資料。此資料可以通過 REST API 以圖形或表格顯示或由外部系統使用。表示式語言允許使用者建立迴歸，分析實時資料或趨勢歷史資料。標籤也是用於過濾和查詢資料的絕佳工具。標籤可以與每個度量標準名稱相關聯。
Prometheus 附帶 AlertManager 來處理警報。AlertManager 允許進行警報聚合以及更復雜的流量以限制傳送警報的時間。假設在開關關閉的同時 10 個節點突然出問題，你可能不需要傳送有關這 10 個節點的告警，因為接到報警的每個人在開關修好之前可能無法執行任何操作。使用 AlertManager，可以僅向網路團隊傳送有關開關告警，並在其中包含其他可能受影響系統的資訊；也可以向系統團隊傳送電子郵件（而不是頁面），以便他們知道這些節點已關閉，除非系統在開關修復後沒有恢復，否則他們不需要響應。 如果發生這種情況，則 AlertManager 將重新啟用那些被開關警報抑制的警報。
GraphiteGraphite 是一款用 Python 寫的開源企業級監控繪圖工具，可以在廉價機硬體上執行。Graphite 可以實時收集、儲存、顯示時間序列型別的資料，它由三個軟體元件組成：
-
carbon - 基於 Twisted 的程序，用於監聽並接收資料；
-
whisper - 專門儲存時序資料的小型資料庫，在設計上類似於 RRD；
-
graphite webapp - 基於 Django 的網頁應用程式，可以從 whisper 資料庫獲取時間序列資料並且進行展示。
Graphite 架構圖
Graphite 是一個基於推送的系統，通過讓應用程式推送資料到 Graphite 的 Carbon 元件中，從應用程式接收資料。 Carbon 將此資料儲存在 Whisper 資料庫中，Graphite Web 元件讀取 Carbon 它的和資料庫，允許使用者在瀏覽器中繪製資料圖或通過 API 提取資料。一個非常酷的功能是能夠將這些圖形匯出為影象或資料檔案，以便將它們輕鬆嵌入到其他應用程式中。
Graphite 的另一個有趣功能是能夠儲存與時序指標相關的任意事件。可以在 Graphite 中新增和跟蹤應用程式或基礎架構部署， 這允許運維人員或開發人員對問題進行故障排除，能獲得正在調查的異常行為環境中更多的背景資訊。
Graphite 監控上手指南：http://www.infoq.com/cn/articles/graphite-intro
InfluxDBInfluxDB 是一個相對較新的時序資料庫，使用 Go 語言編寫，無需外部依賴，安裝配置非常方便，適合構建大型分散式系統的監控系統。
其設計目標是實現分散式和水平伸縮擴充套件。
InfluxDB 的一些主要特徵：
-
無結構 (無模式)：可以是任意數量的列
-
可以設定 metric 的儲存時間
-
支援與時間有關的相關函式 (如 min、max、sum、count、mean、median 等)，方便統計
-
支援儲存策略: 可以用於資料的刪改。(influxDB 沒有提供資料的刪除與修改方法)
-
支援連續查詢: 是資料庫中自動定時啟動的一組語句，和儲存策略搭配可以降低 InfluxDB 的系統佔用量。
-
原生的 HTTP 支援，內建 HTTP API
-
支援類似 sql 語法
-
支援設定資料在叢集中的副本數
-
支援定期取樣資料，寫入另外的 measurement，方便分粒度儲存資料
-
自帶 web 管理介面，方便使用 (登入方式：http://< InfluxDB-IP >:8083)
OpenTSDB 是基於 Hbase 的分散式的，可伸縮的時序資料庫，確切地說，它只是一個 HBase 的應用。OpenTSDB 主要用途就是做監控系統；譬如收集大規模叢集（包括網路裝置、作業系統、應用程式、環境狀態）的監控資料並進行儲存，查詢。
OpenTSDB 可以動態的增加 metrics，靈活支援任何語言的收集器，極大的方便了運維人員，降低了開發和維護成本。
儲存到 OpenTSDB 的資料，是以 metric 為單位的，metric 就是一個監控項，譬如伺服器的話，會有 CPU 使用率、記憶體使用率這些 metric；
OpenTSDB 使用 HBase 作為儲存，由於有良好的設計，因此對 metric 的資料儲存支援到秒級別；
OpenTSDB 支援資料永久儲存，即儲存的資料不會主動刪除；並且原始資料會一直儲存（有些監控系統會將較久之前的資料聚合之後儲存）
日誌聚合工具
一些日誌記錄規則：
-
包括時間戳
-
格式為 JSON
-
請勿記錄無意義的事件
-
請記錄所有應用程式錯誤
-
可以有日誌警告
-
開啟日誌記錄
-
以可讀的形式寫訊息
-
請勿在生產中記錄資訊資料
-
請勿記錄無法閱讀或反應的任何內容
ELK 是 Elasticsearch，Logstash 和 Kibana 的縮寫，在實時資料檢索和分析場合，三者通常是配合共用，是市場上最受歡迎的開源日誌聚合工具。它被 Netflix，Facebook，Microsoft，LinkedIn 和 Cisco 使用。這三個元件都是由 Elastic 開發和維護的。Elasticsearch 本質上是一個 NoSQL，以 Lucene 搜尋引擎實現。 Logstash 是一個日誌管道系統，可以提取、轉換資料並將其載入到像 Elasticsearch 這樣的商店中。 Kibana 是 Elasticsearch 之上的視覺化層。
幾年前出現了資料收集器 Beats，能簡化資料傳輸到 Logstash 的過程。使用者可以安裝 Beat，能匯出 NGINX 日誌或 Envoy 代理日誌，以便在 Elasticsearch 中有效使用，無需瞭解每種型別日誌的正確語法。
在安裝生產級 ELK 堆疊時，可能會包含 Kafka，Redis 和 NGINX 等其他部分。此外，Logstash 通常可以用 Fluentd 替換。這個系統操作起來很複雜，早期有很多問題導致了很多抱怨。 這些問題很大程度上都被修復了，但它仍然是一個複雜的系統，所以對於較小的操作，你可能不想嘗試它。
ELK 堆疊還通過 Kibana 提供了出色的視覺化工具，但它缺乏警報功能。 Elastic 在付費 X-Pack 外掛中提供警報功能，但開源系統中沒有內建任何功能。Yelp 為這個問題提供了名為 ElastAlert 的解決方案，可能還有其他類似的工具。這個額外的軟體非常強大，但它進一步增加了 ELK 堆疊的複雜性。
ELK Stack 在最近兩年迅速崛起，和傳統的日誌處理方案相比，ELK Stack 具有如下幾個優點：
-
處理方式靈活。Elasticsearch 是實時全文索引，不需要像 storm 那樣預先程式設計才能使用 ;
-
配置簡易上手。Elasticsearch 全部採用 JSON 介面，Logstash 是 Ruby DSL 設計，都是目前業界最通用的配置語法設計 ;
-
檢索效能高效。雖然每次查詢都是實時計算，但是優秀的設計和實現基本可以達到全天資料查詢的秒級響應 ;
-
叢集線性擴充套件。不管是 Elasticsearch 叢集還是 Logstash 叢集都是可以線性擴充套件的 ;
-
前端操作炫麗。Kibana 介面上，只需要點選滑鼠，就可以完成搜尋、聚合功能，生成炫麗的儀表板。
Graylog 是強大的日誌管理、分析工具，基於 Elasticsearch, Java 和 MongoDB，這使得它像 ELK 堆疊一樣執行起來很複雜，甚至更加複雜。但是，Graylog 開源版本帶有內建的警報，以及其他一些值得注意的功能，如流式傳輸，訊息重寫和地理定位。
流式傳輸功能允許資料在處理時能實時路由到特定 Stream。使用此功能，使用者可以在一個 Stream 中檢視所有資料庫錯誤，在另一個 Stream 中檢視 Web 伺服器錯誤。當新增新專案或超過閾值時，告警甚至可以基於這些 Stream。延遲可能是日誌聚合系統的最大問題之一，Graylog 中的 Streams 中消除了這個問題，一旦日誌進入，無需處理即可通過 Stream 路由到其他系統。
訊息重寫功能使用開源規則引擎 Drools，允許根據使用者定義的規則檔案來評估所有傳入訊息。該檔案可以丟棄訊息（稱為黑名單），新增或刪除欄位，以及修改資訊。
Graylog 最酷的功能可能是地理位置功能，它支援在地圖上繪製 IP 地址。這樣功能相當常見，Kibana 中也有這個功能，但 Graylog 中增加了很多價值，特別是你想將它用作 SIEM 系統時。地理定位功能在 Graylog 的開源版本中提供。
圖片來源：https://testerhome.com/topics/3026
Graylog 吸引人的地方：
-
一體化方案，安裝方便，不像 ELK 有 3 個獨立系統間的整合問題。
-
採集原始日誌，並可以事後再新增欄位，比如 http_status_code，response_time 等等。
-
自己開發採集日誌的指令碼，並用 curl/nc 傳送到 Graylog Server，傳送格式是自定義的 GELF，Flunted 和 Logstash 都有相應的輸出 GELF 訊息的外掛。自己開發帶來很大的自由度。實際上只需要用 inotifywait 監控日誌的 modify 事件，並把日誌的新增行用 curl/netcat 傳送到 Graylog Server 就可。
-
搜尋結果高亮顯示，就像 google 一樣。
-
搜尋語法簡單，比如： source:mongo AND reponse_time_ms:>5000，避免直接輸入 elasticsearch 搜尋 json 語法。
-
搜尋條件可以匯出為 elasticsearch 的搜尋 json 文字，方便直接開發呼叫 elasticsearch rest api 的搜尋指令碼。
Graylog 開源版官網： https://www.graylog.org/
FluentdFluentd 是一個完全開源免費的 log 資訊收集軟體，支援超過 125 個系統的 log 資訊收集，用 C 和 Ruby 編寫，被 CNCF 接受為孵化專案，並得到了 AWS 和 Google Cloud 的推薦。在許多安裝中，Fluentd 已成為 Logstash 的常見替代工具，充當本地聚合器，用於收集所有節點日誌併發送到中央儲存系統。但 Fluentd 不是一個日誌整合系統。
圖片來源：http://www.muzixing.com/pages/2017/02/05/fluentdru-men-jiao-cheng.html
Fluentd 使用強大的外掛系統，有超過 500 個外掛可供使用，可快速輕鬆地整合不同的資料來源和資料輸出，涵蓋你的大部分用例。
Fluentd 記憶體要求低（僅幾十兆位元組），有高吞吐量，因此是 Kubernetes 環境中的常見選擇。在像 Kubernetes 這樣的環境中，每個 Pod 都有一個 Fluentd side-car，記憶體消耗將隨著每個新 Pod 的建立而線性增加。使用 Fluentd 將大大降低系統利用率。
告警和視覺化工具通過名稱就可以知道告警和視覺化工具的用途，告警和視覺化系統專注於理解其他系統的輸出。這就是他們被歸為一組的原因。視覺化和警報工具可以將系統輸出結構化地表示出來。
告警和視覺化常見型別
首先，我們要弄清楚哪些不是告警。如果響應人員無法對問題採取任何措施，那麼告警就不應該傳送。這種情景包括髮送給多個人，但只有少數人可以響應的的告警。
例如，如果操作員每天從警報系統收到數百封電子郵件，他將忽略來自警報系統的所有電子郵件，只有在遇到問題，客戶傳送電子郵件或老闆打電話時才會迴應真實事件。在這種情況下，警報已失去其意義和用途。
警報不應該是一連串的資訊或狀態更新。它們只是許多系統稱為警報的資料點，代表了一些應該被知曉但沒有被響應的事件。這些資訊通常是警報工具的視覺化系統的一部分，而不是觸發實際通知的事件。
告警可以分為兩類：內部中斷和外部中斷。在這個模型中，系統性能降級被視為中斷，因為通常不知道每個使用者的影響有多嚴重。
內部中斷的優先順序低於外部中斷，但仍需要快速響應。內部中斷通常涉及公司員工使用的內部系統或僅對公司員工可見的應用程式元件。
外部中斷包括任何會立即影響客戶的系統中斷。這些不包括影響系統更新發布的系統中斷，但包括面向客戶的應用程式故障，資料庫中斷和網路分割槽等，還包括可能對使用者沒有直接影響的工具故障。
視覺化常見的視覺化和理解系統的方案有：
折線圖：折線圖可能是最常見和最普遍的視覺化。隨著時間的推移，折線圖可以很好地理解系統。也可以堆疊折線圖以顯示關係。例如，你可能希望單獨檢視每個伺服器上的請求，但也可以聚合檢視。
熱圖：另一種常見的視覺化是熱圖，配合直方圖檢視很有用。這種型別的視覺化類似於條形圖，但可以在條形圖中顯示錶示整體度量標準的不同百分位數的漸變。
例如，你可能正在檢視請求延遲，並希望快速瞭解所有請求的總體趨勢和分佈。熱圖對此非常有用，可以通過顏色快速瀏覽每個部分的數量。
gauge ：gauge 是單值計量視覺化。gauge 的面貌可以是半圓表或全圓表。您可以自定義內線和外線的厚度以達到所需的設計美學效果。測量儀和文字的顏色可根據一組規則完全自定義。
火焰圖：火焰圖是基於 perf 結果產生的 SVG 圖片，用來展示 CPU 的呼叫棧。
y 軸表示呼叫棧，每一層都是一個函式。呼叫棧越深，火焰就越高，頂部就是正在執行的函式，下方都是它的父函式。
x 軸表示抽樣數，如果一個函式在 x 軸佔據的寬度越寬，就表示它被抽到的次數多，即執行的時間長。注意，x 軸不代表時間，而是所有的呼叫棧合併後，按字母順序排列的。
告警工具 Bosun
Bosun 是一個新型的監控和告警系統，由 Stack Exchange 團隊打造，使用 golang 編寫，支援定義複雜的告警規則，支援 OpenTSDB、Graphite、Logstash-Elasticsearch 等資料來源。Bosun 將是 zabbix、nagios 的有力競爭者。
圖片來源：http://blog.tangyingkang.com/post/2016/12/06/bosun-alert-guide/
Bosun 的一個非常巧妙的功能是它可以讓你根據歷史資料測試警報。Bosun 還具有一些常見的功能，如顯示簡單的圖形和建立警報。Bosun 通過表示式語言來查詢監控指標，可以看成是一個簡易的程式語言集，這在使它變得靈活強大的同時，也令它略顯複雜。
Cabot
Cabot 是一個免費開源的輕量級監控報警服務，集合了 PagerDuty，Server Density，Pingdom 和 Nagios 所具備的一些最佳功能，但是沒有這些工具複雜，也不如它們成本高。
Cabot 的架構和 Bosun 類似，都不收集資料。原生支援 Graphite 和 Jenkins，比較少見。
Cabot 提供了一個 Web 介面，允許監控服務（例如“Stage Redis 伺服器”，“生產 ElasticSearch 叢集”），並在服務發生故障時向值班團隊傳送電話，簡訊或電子郵件警報，連一行程式碼都不需要你寫。
Catbot 的報警可以基於：
-
graphite 收集的監控資料；
-
url 的響應內容和狀態碼；
-
jenkins 編譯任務的狀態；
而不需要實現和維護一個全新的資料收集器系統。
視覺化工具Grafana 是用於視覺化大型測量資料的開源程式，使用 Go 語言開發，功能齊全，有著好看的儀表盤和圖表，可用來做日誌的分析與展示曲線圖（如 API 的請求日誌），支援多種 backend，如 ElasticSearch、InfluxDB、OpenTSDB 等等，最常用於網路基礎設施和應用分析，具有熱插拔控制面板和可擴充套件的資料來源，
使用 grafana 可以直觀地設定警報。這意味著你可以檢視圖表，甚至可以檢視由於系統性能下降而應該觸發警報的位置，單擊要觸發警報的圖表，然後告訴 Grafana 將警報傳送到何處。 這是一個非常強大的補充新能，不一定會取代警報平臺，但肯定可以增強告警功能。
從本質上說，Grafana 是一個功能豐富的 Graphite-web 替代品，能幫助使用者更簡單地建立和編輯儀表盤。它包含一個獨一無二的 Graphite 目標解析器，從而可以簡化度量和函式的編輯。Grafana 快速的客戶端渲染預設使用的是 Flot ，即使很長的時間範圍也可應對，這樣使用者就可以建立具有智慧軸格式（比如線和點）的複雜圖表了。
Vizceral
Vizceral 是 Netflix 釋出的一個開源專案，用於近乎實時地監控應用程式和叢集之間的網路流量。
Vizceral 是一組採用 WebG 標準實現的動態展示線路圖元件，可以實現資料的檢視以及互動，分為全域性、部分割槽域、水平三個維度，使資料更為直觀明瞭的展示。
Vizceral 元件可以採取多個流量圖，並將生成一個“全域性”圖，顯示所有傳入的流量到每個“區域”，支援跨區域通訊。
Netflix 區域間流量圖
參考資料
https://opensource.com/article/18/8/now-available-open-source-guide-devops-monitoring-tools