一些好用的開源監控工具匯總

科技 10-08

編輯 | 張嬋 - 高效開發運維

監控系統是整個 IT 架構中的重中之重，小到故障排查、問題定位，大到業務預測、運營管理，都離不開監控系統，可以說一個穩定、健康的 IT 架構中必然會有一個可信賴的監控系統。

但是，難道監控就只是監控？多年來，對於監控的術語一直都有很多困惑，一些很糟糕的工具也宣稱能夠以一種格式完成所有事情。

在 DevOps 和雲原生時代，今年，「可觀察性」（Observability）被引入到了 IT 領域，其首先表現為 CNCF-Landscape 出現了 Observability 分組。從該分組的內容看包含了監控，日誌，Tracing 等領域的項目。可觀察性與監控有什麼不同？簡單說來，後者是前者的一個子集。監控關注系統的失敗因素，從而定義出系統的失敗模型。它的核心是運維，是監控設施。而可觀察性除了關註失敗之外，其核心是研發，是應用，是對系統的一種自我審視。是站在創造者的角度去探究系統應如何恰當的展現自身的狀態。一個由外向內，一個由內向外。

觀察工具包括：度量聚合（Metrics aggregation）（主要是時序數據），日誌聚合（Log aggregation），告警／可視化（Alerting/visualizations），分散式追蹤（Distributed tracing）。

監控工具

Prometheus

Prometheus 是雲原生應用程序最受認可的時間序列監控解決方案，由 CNCF 託管，使用 Go 語言開發，是 Google BorgMon 監控系統的類似實現。

Prometheus 使用的是 Pull 模型，Prometheus Server 通過 HTTP 的 pull 方式到各個目標拉取監控數據。它使用局部配置來描述要收集的端點和收集所需的間隔。每個端點都有一個客戶端收集數據並在每次請求時更新該表示（或者客戶端是配置的）。收集此數據並將其保存在本地磁碟上的高效存儲引擎中。存儲系統使用每個度量標準的僅附加文件。

Prometheus 包含一種高級表達式語言，用於選擇和顯示名為 PromQL 的數據。此數據可以通過 REST API 以圖形或表格顯示或由外部系統使用。表達式語言允許用戶創建回歸，分析實時數據或趨勢歷史數據。標籤也是用於過濾和查詢數據的絕佳工具。標籤可以與每個度量標準名稱相關聯。

Prometheus 附帶 AlertManager 來處理警報。AlertManager 允許進行警報聚合以及更複雜的流量以限制發送警報的時間。假設在開關關閉的同時 10 個節點突然出問題，你可能不需要發送有關這 10 個節點的告警，因為接到報警的每個人在開關修好之前可能無法執行任何操作。使用 AlertManager，可以僅向網路團隊發送有關開關告警，並在其中包含其他可能受影響系統的信息；也可以向系統團隊發送電子郵件（而不是頁面），以便他們知道這些節點已關閉，除非系統在開關修復後沒有恢復，否則他們不需要響應。如果發生這種情況，則 AlertManager 將重新激活那些被開關警報抑制的警報。

Graphite

Graphite 是一款用 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

InfluxDB

InfluxDB 是一個相對較新的時序資料庫，使用 Go 語言編寫，無需外部依賴，安裝配置非常方便，適合構建大型分散式系統的監控系統。

其設計目標是實現分散式和水平伸縮擴展。

InfluxDB 的一些主要特徵：

無結構 (無模式)：可以是任意數量的列

可以設置 metric 的保存時間

支持與時間有關的相關函數 (如 min、max、sum、count、mean、median 等)，方便統計

支持存儲策略: 可以用於數據的刪改。(influxDB 沒有提供數據的刪除與修改方法)

支持連續查詢: 是資料庫中自動定時啟動的一組語句，和存儲策略搭配可以降低 InfluxDB 的系統佔用量。

原生的 HTTP 支持，內置 HTTP API

支持類似 sql 語法

支持設置數據在集群中的副本數

支持定期採樣數據，寫入另外的 measurement，方便分粒度存儲數據

自帶 web 管理界面，方便使用 (登入方式：http://:8083)

OpenTSDB

OpenTSDB 是基於 Hbase 的分散式的，可伸縮的時序資料庫，確切地說，它只是一個 HBase 的應用。OpenTSDB 主要用途就是做監控系統；譬如收集大規模集群（包括網路設備、操作系統、應用程序、環境狀態）的監控數據並進行存儲，查詢。

OpenTSDB 可以動態的增加 metrics，靈活支持任何語言的收集器，極大的方便了運維人員，降低了開發和維護成本。

存儲到 OpenTSDB 的數據，是以 metric 為單位的，metric 就是一個監控項，譬如伺服器的話，會有 CPU 使用率、內存使用率這些 metric；

OpenTSDB 使用 HBase 作為存儲，由於有良好的設計，因此對 metric 的數據存儲支持到秒級別；

OpenTSDB 支持數據永久存儲，即保存的數據不會主動刪除；並且原始數據會一直保存（有些監控系統會將較久之前的數據聚合之後保存）

日誌聚合工具

一些日誌記錄規則：

包括時間戳

格式為 JSON

請勿記錄無意義的事件

請記錄所有應用程序錯誤

可以有日誌警告

打開日誌記錄

以可讀的形式寫消息

請勿在生產中記錄信息數據

請勿記錄無法閱讀或反應的任何內容

ELK

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

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/

Fluentd

Fluentd 是一個完全開源免費的 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

Grafana 是用於可視化大型測量數據的開源程序，使用 Go 語言開發，功能齊全，有著好看的儀錶盤和圖表，可用來做日誌的分析與展示曲線圖（如 API 的請求日誌），支持多種 backend，如 ElasticSearch、InfluxDB、OpenTSDB 等等，最常用於網路基礎設施和應用分析，具有熱插拔控制面板和可擴展的數據源，

使用 grafana 可以直觀地設置警報。這意味著你可以查看圖表，甚至可以查看由於系統性能下降而應該觸發警報的位置，單擊要觸發警報的圖表，然後告訴 Grafana 將警報發送到何處。這是一個非常強大的補充新能，不一定會取代警報平台，但肯定可以增強告警功能。

從本質上說，Grafana 是一個功能豐富的 Graphite-web 替代品，能幫助用戶更簡單地創建和編輯儀錶盤。它包含一個獨一無二的 Graphite 目標解析器，從而可以簡化度量和函數的編輯。Grafana 快速的客戶端渲染默認使用的是 Flot ，即使很長的時間範圍也可應對，這樣用戶就可以創建具有智能軸格式（比如線和點）的複雜圖表了。