監(jiān)控系統(tǒng)是整個 IT 架構(gòu)中的重中之重，小到故障排查、問題定位，大到業(yè)務(wù)預(yù)測、運營管理，都離不開監(jiān)控系統(tǒng)，可以說一個穩(wěn)定、健康的 IT 架構(gòu)中必然會有一個可信賴的監(jiān)控系統(tǒng)。

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

在 DevOps 和云原生時代，今年，“可觀察性”（Observability）被引入到了 IT 領(lǐng)域，其首先表現(xiàn)為 CNCF-Landscape 出現(xiàn)了 Observability 分組。從該分組的內(nèi)容看包含了監(jiān)控，日志，Tracing 等領(lǐng)域的項目?？捎^察性與監(jiān)控有什么不同？簡單說來，后者是前者的一個子集。監(jiān)控關(guān)注系統(tǒng)的失敗因素，從而定義出系統(tǒng)的失敗模型。它的核心是運維，是監(jiān)控設(shè)施。而可觀察性除了關(guān)注失敗之外，其核心是研發(fā)，是應(yīng)用，是對系統(tǒng)的一種自我審視。是站在創(chuàng)造者的角度去探究系統(tǒng)應(yīng)如何恰當(dāng)?shù)恼宫F(xiàn)自身的狀態(tài)。一個由外向內(nèi)，一個由內(nèi)向外。

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

Prometheus 是云原生應(yīng)用程序最受認可的時間序列監(jiān)控解決方案，由 CNCF 托管，使用 Go 語言開發(fā)，是 Google BorgMon 監(jiān)控系統(tǒng)的類似實現(xiàn)。

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

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

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

Graphite 是一款用 Python 寫的開源企業(yè)級監(jiān)控繪圖工具，可以在廉價機硬件上運行。Graphite 可以實時收集、存儲、顯示時間序列類型的數(shù)據(jù)，它由三個軟件組件組成：

• carbon - 基于 Twisted 的進程，用于監(jiān)聽并接收數(shù)據(jù)；

• whisper - 專門存儲時序數(shù)據(jù)的小型數(shù)據(jù)庫，在設(shè)計上類似于 RRD；

• graphite webapp - 基于 Django 的網(wǎng)頁應(yīng)用程序，可以從 whisper 數(shù)據(jù)庫獲取時間序列數(shù)據(jù)并且進行展示。

Graphite 架構(gòu)圖

Graphite 是一個基于推送的系統(tǒng)，通過讓應(yīng)用程序推送數(shù)據(jù)到 Graphite 的 Carbon 組件中，從應(yīng)用程序接收數(shù)據(jù)。 Carbon 將此數(shù)據(jù)存儲在 Whisper 數(shù)據(jù)庫中，Graphite Web 組件讀取 Carbon 它的和數(shù)據(jù)庫，允許用戶在瀏覽器中繪制數(shù)據(jù)圖或通過 API 提取數(shù)據(jù)。一個非?？岬墓δ苁悄軌?qū)⑦@些圖形導(dǎo)出為圖像或數(shù)據(jù)文件，以便將它們輕松嵌入到其他應(yīng)用程序中。

Graphite 的另一個有趣功能是能夠存儲與時序指標相關(guān)的任意事件?？梢栽?Graphite 中添加和跟蹤應(yīng)用程序或基礎(chǔ)架構(gòu)部署， 這允許運維人員或開發(fā)人員對問題進行故障排除，能獲得正在調(diào)查的異常行為環(huán)境中更多的背景信息。

Graphite 監(jiān)控上手指南：http://www./cn/articles/graphite-intro

InfluxDB 是一個相對較新的時序數(shù)據(jù)庫，使用 Go 語言編寫，無需外部依賴，安裝配置非常方便，適合構(gòu)建大型分布式系統(tǒng)的監(jiān)控系統(tǒng)。

其設(shè)計目標是實現(xiàn)分布式和水平伸縮擴展。

InfluxDB 的一些主要特征：

• 無結(jié)構(gòu) (無模式)：可以是任意數(shù)量的列

• 可以設(shè)置 metric 的保存時間

• 支持與時間有關(guān)的相關(guān)函數(shù) (如 min、max、sum、count、mean、median 等)，方便統(tǒng)計

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

• 支持連續(xù)查詢: 是數(shù)據(jù)庫中自動定時啟動的一組語句，和存儲策略搭配可以降低 InfluxDB 的系統(tǒng)占用量。

• 原生的 HTTP 支持，內(nèi)置 HTTP API

• 支持類似 sql 語法

• 支持設(shè)置數(shù)據(jù)在集群中的副本數(shù)

• 支持定期采樣數(shù)據(jù)，寫入另外的 measurement，方便分粒度存儲數(shù)據(jù)

• 自帶 web 管理界面，方便使用 (登入方式：http://< influxdb-ip="">:8083)

OpenTSDB 是基于 Hbase 的分布式的，可伸縮的時序數(shù)據(jù)庫，確切地說，它只是一個 HBase 的應(yīng)用。OpenTSDB 主要用途就是做監(jiān)控系統(tǒng)；譬如收集大規(guī)模集群（包括網(wǎng)絡(luò)設(shè)備、操作系統(tǒng)、應(yīng)用程序、環(huán)境狀態(tài)）的監(jiān)控數(shù)據(jù)并進行存儲，查詢。

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

存儲到 OpenTSDB 的數(shù)據(jù)，是以 metric 為單位的，metric 就是一個監(jiān)控項，譬如服務(wù)器的話，會有 CPU 使用率、內(nèi)存使用率這些 metric；

OpenTSDB 使用 HBase 作為存儲，由于有良好的設(shè)計，因此對 metric 的數(shù)據(jù)存儲支持到秒級別；

OpenTSDB 支持數(shù)據(jù)永久存儲，即保存的數(shù)據(jù)不會主動刪除；并且原始數(shù)據(jù)會一直保存（有些監(jiān)控系統(tǒng)會將較久之前的數(shù)據(jù)聚合之后保存）

一些日志記錄規(guī)則：

• 包括時間戳

• 格式為 JSON

• 請勿記錄無意義的事件

• 請記錄所有應(yīng)用程序錯誤

• 可以有日志警告

• 打開日志記錄

• 以可讀的形式寫消息

• 請勿在生產(chǎn)中記錄信息數(shù)據(jù)

• 請勿記錄無法閱讀或反應(yīng)的任何內(nèi)容

ELK 是 Elasticsearch，Logstash 和 Kibana 的縮寫，在實時數(shù)據(jù)檢索和分析場合，三者通常是配合共用，是市場上最受歡迎的開源日志聚合工具。它被 Netflix，F(xiàn)acebook，Microsoft，LinkedIn 和 Cisco 使用。這三個組件都是由 Elastic 開發(fā)和維護的。Elasticsearch 本質(zhì)上是一個 NoSQL，以 Lucene 搜索引擎實現(xiàn)。 Logstash 是一個日志管道系統(tǒng)，可以提取、轉(zhuǎn)換數(shù)據(jù)并將其加載到像 Elasticsearch 這樣的商店中。 Kibana 是 Elasticsearch 之上的可視化層。

幾年前出現(xiàn)了數(shù)據(jù)收集器 Beats，能簡化數(shù)據(jù)傳輸?shù)?Logstash 的過程。用戶可以安裝 Beat，能導(dǎo)出 NGINX 日志或 Envoy 代理日志，以便在 Elasticsearch 中有效使用，無需了解每種類型日志的正確語法。

在安裝生產(chǎn)級 ELK 堆棧時，可能會包含 Kafka，Redis 和 NGINX 等其他部分。此外，Logstash 通?？梢杂?Fluentd 替換。這個系統(tǒng)操作起來很復(fù)雜，早期有很多問題導(dǎo)致了很多抱怨。 這些問題很大程度上都被修復(fù)了，但它仍然是一個復(fù)雜的系統(tǒng)，所以對于較小的操作，你可能不想嘗試它。

ELK 堆棧還通過 Kibana 提供了出色的可視化工具，但它缺乏警報功能。 Elastic 在付費 X-Pack 插件中提供警報功能，但開源系統(tǒng)中沒有內(nèi)置任何功能。Yelp 為這個問題提供了名為 ElastAlert 的解決方案，可能還有其他類似的工具。這個額外的軟件非常強大，但它進一步增加了 ELK 堆棧的復(fù)雜性。

ELK Stack 在最近兩年迅速崛起，和傳統(tǒng)的日志處理方案相比，ELK Stack 具有如下幾個優(yōu)點：

• 處理方式靈活。Elasticsearch 是實時全文索引，不需要像 storm 那樣預(yù)先編程才能使用 ;

• 配置簡易上手。Elasticsearch 全部采用 JSON 接口，Logstash 是 Ruby DSL 設(shè)計，都是目前業(yè)界最通用的配置語法設(shè)計 ;

• 檢索性能高效。雖然每次查詢都是實時計算，但是優(yōu)秀的設(shè)計和實現(xiàn)基本可以達到全天數(shù)據(jù)查詢的秒級響應(yīng) ;

• 集群線性擴展。不管是 Elasticsearch 集群還是 Logstash 集群都是可以線性擴展的 ;

• 前端操作炫麗。Kibana 界面上，只需要點擊鼠標，就可以完成搜索、聚合功能，生成炫麗的儀表板。

Graylog 是強大的日志管理、分析工具，基于 Elasticsearch, Java 和 MongoDB，這使得它像 ELK 堆棧一樣運行起來很復(fù)雜，甚至更加復(fù)雜。但是，Graylog 開源版本帶有內(nèi)置的警報，以及其他一些值得注意的功能，如流式傳輸，消息重寫和地理定位。

流式傳輸功能允許數(shù)據(jù)在處理時能實時路由到特定 Stream。使用此功能，用戶可以在一個 Stream 中查看所有數(shù)據(jù)庫錯誤，在另一個 Stream 中查看 Web 服務(wù)器錯誤。當(dāng)添加新項目或超過閾值時，告警甚至可以基于這些 Stream。延遲可能是日志聚合系統(tǒng)的最大問題之一，Graylog 中的 Streams 中消除了這個問題，一旦日志進入，無需處理即可通過 Stream 路由到其他系統(tǒng)。

消息重寫功能使用開源規(guī)則引擎 Drools，允許根據(jù)用戶定義的規(guī)則文件來評估所有傳入消息。該文件可以丟棄消息（稱為黑名單），添加或刪除字段，以及修改信息。

Graylog 最酷的功能可能是地理位置功能，它支持在地圖上繪制 IP 地址。這樣功能相當(dāng)常見，Kibana 中也有這個功能，但 Graylog 中增加了很多價值，特別是你想將它用作 SIEM 系統(tǒng)時。地理定位功能在 Graylog 的開源版本中提供。

圖片來源：https:///topics/3026

Graylog 吸引人的地方：

• 一體化方案，安裝方便，不像 ELK 有 3 個獨立系統(tǒng)間的集成問題。

• 采集原始日志，并可以事后再添加字段，比如 http_status_code，response_time 等等。

• 自己開發(fā)采集日志的腳本，并用 curl/nc 發(fā)送到 Graylog Server，發(fā)送格式是自定義的 GELF，F(xiàn)lunted 和 Logstash 都有相應(yīng)的輸出 GELF 消息的插件。自己開發(fā)帶來很大的自由度。實際上只需要用 inotifywait 監(jiān)控日志的 modify 事件，并把日志的新增行用 curl/netcat 發(fā)送到 Graylog Server 就可。

• 搜索結(jié)果高亮顯示，就像 google 一樣。

• 搜索語法簡單，比如： source:mongo AND reponse_time_ms:>5000，避免直接輸入 elasticsearch 搜索 json 語法。

• 搜索條件可以導(dǎo)出為 elasticsearch 的搜索 json 文本，方便直接開發(fā)調(diào)用 elasticsearch rest api 的搜索腳本。

Graylog 開源版官網(wǎng)： https://www./

Fluentd 是一個完全開源免費的 log 信息收集軟件，支持超過 125 個系統(tǒng)的 log 信息收集，用 C 和 Ruby 編寫，被 CNCF 接受為孵化項目，并得到了 AWS 和 Google Cloud 的推薦。在許多安裝中，F(xiàn)luentd 已成為 Logstash 的常見替代工具，充當(dāng)本地聚合器，用于收集所有節(jié)點日志并發(fā)送到中央存儲系統(tǒng)。但 Fluentd 不是一個日志集成系統(tǒng)。

圖片來源：http://www./pages/2017/02/05/fluentdru-men-jiao-cheng.html

Fluentd 使用強大的插件系統(tǒng)，有超過 500 個插件可供使用，可快速輕松地集成不同的數(shù)據(jù)源和數(shù)據(jù)輸出，涵蓋你的大部分用例。

Fluentd 內(nèi)存要求低（僅幾十兆字節(jié)），有高吞吐量，因此是 Kubernetes 環(huán)境中的常見選擇。在像 Kubernetes 這樣的環(huán)境中，每個 Pod 都有一個 Fluentd side-car，內(nèi)存消耗將隨著每個新 Pod 的創(chuàng)建而線性增加。使用 Fluentd 將大大降低系統(tǒng)利用率。

通過名稱就可以知道告警和可視化工具的用途，告警和可視化系統(tǒng)專注于理解其他系統(tǒng)的輸出。這就是他們被歸為一組的原因?？梢暬途瘓蠊ぞ呖梢詫⑾到y(tǒng)輸出結(jié)構(gòu)化地表示出來。

首先，我們要弄清楚哪些不是告警。如果響應(yīng)人員無法對問題采取任何措施，那么告警就不應(yīng)該發(fā)送。這種情景包括發(fā)送給多個人，但只有少數(shù)人可以響應(yīng)的的告警。

例如，如果操作員每天從警報系統(tǒng)收到數(shù)百封電子郵件，他將忽略來自警報系統(tǒng)的所有電子郵件，只有在遇到問題，客戶發(fā)送電子郵件或老板打電話時才會回應(yīng)真實事件。在這種情況下，警報已失去其意義和用途。

警報不應(yīng)該是一連串的信息或狀態(tài)更新。它們只是許多系統(tǒng)稱為警報的數(shù)據(jù)點，代表了一些應(yīng)該被知曉但沒有被響應(yīng)的事件。這些信息通常是警報工具的可視化系統(tǒng)的一部分，而不是觸發(fā)實際通知的事件。

告警可以分為兩類：內(nèi)部中斷和外部中斷。在這個模型中，系統(tǒng)性能降級被視為中斷，因為通常不知道每個用戶的影響有多嚴重。

內(nèi)部中斷的優(yōu)先級低于外部中斷，但仍需要快速響應(yīng)。內(nèi)部中斷通常涉及公司員工使用的內(nèi)部系統(tǒng)或僅對公司員工可見的應(yīng)用程序組件。

外部中斷包括任何會立即影響客戶的系統(tǒng)中斷。這些不包括影響系統(tǒng)更新發(fā)布的系統(tǒng)中斷，但包括面向客戶的應(yīng)用程序故障，數(shù)據(jù)庫中斷和網(wǎng)絡(luò)分區(qū)等，還包括可能對用戶沒有直接影響的工具故障。

常見的可視化和理解系統(tǒng)的方案有：

折線圖：折線圖可能是最常見和最普遍的可視化。隨著時間的推移，折線圖可以很好地理解系統(tǒng)。也可以堆疊折線圖以顯示關(guān)系。例如，你可能希望單獨查看每個服務(wù)器上的請求，但也可以聚合查看。

熱圖：另一種常見的可視化是熱圖，配合直方圖查看很有用。這種類型的可視化類似于條形圖，但可以在條形圖中顯示表示整體度量標準的不同百分位數(shù)的漸變。

例如，你可能正在查看請求延遲，并希望快速了解所有請求的總體趨勢和分布。熱圖對此非常有用，可以通過顏色快速瀏覽每個部分的數(shù)量。

gauge：gauge 是單值計量可視化。gauge 的面貌可以是半圓表或全圓表。您可以自定義內(nèi)線和外線的厚度以達到所需的設(shè)計美學(xué)效果。測量儀和文本的顏色可根據(jù)一組規(guī)則完全自定義。

火焰圖：火焰圖是基于 perf 結(jié)果產(chǎn)生的 SVG 圖片，用來展示 CPU 的調(diào)用棧。

y 軸表示調(diào)用棧，每一層都是一個函數(shù)。調(diào)用棧越深，火焰就越高，頂部就是正在執(zhí)行的函數(shù)，下方都是它的父函數(shù)。

x 軸表示抽樣數(shù)，如果一個函數(shù)在 x 軸占據(jù)的寬度越寬，就表示它被抽到的次數(shù)多，即執(zhí)行的時間長。注意，x 軸不代表時間，而是所有的調(diào)用棧合并后，按字母順序排列的。

Bosun 是一個新型的監(jiān)控和告警系統(tǒng)，由 Stack Exchange 團隊打造，使用 golang 編寫，支持定義復(fù)雜的告警規(guī)則，支持 OpenTSDB、Graphite、Logstash-Elasticsearch 等數(shù)據(jù)源。Bosun 將是 zabbix、nagios 的有力競爭者。

圖片來源：http://blog./post/2016/12/06/bosun-alert-guide/

Bosun 的一個非常巧妙的功能是它可以讓你根據(jù)歷史數(shù)據(jù)測試警報。Bosun 還具有一些常見的功能，如顯示簡單的圖形和創(chuàng)建警報。Bosun 通過表達式語言來查詢監(jiān)控指標，可以看成是一個簡易的編程語言集，這在使它變得靈活強大的同時，也令它略顯復(fù)雜。

Cabot 是一個免費開源的輕量級監(jiān)控報警服務(wù)，集合了 PagerDuty，Server Density，Pingdom 和 Nagios 所具備的一些最佳功能，但是沒有這些工具復(fù)雜，也不如它們成本高。

Cabot 的架構(gòu)和 Bosun 類似，都不收集數(shù)據(jù)。原生支持 Graphite 和 Jenkins，比較少見。

Cabot 提供了一個 Web 界面，允許監(jiān)控服務(wù)（例如“Stage Redis 服務(wù)器”，“生產(chǎn) ElasticSearch 集群”），并在服務(wù)發(fā)生故障時向值班團隊發(fā)送電話，短信或電子郵件警報，連一行代碼都不需要你寫。

Catbot 的報警可以基于：

• graphite 收集的監(jiān)控數(shù)據(jù)；

• url 的響應(yīng)內(nèi)容和狀態(tài)碼；

• jenkins 編譯任務(wù)的狀態(tài)；

而不需要實現(xiàn)和維護一個全新的數(shù)據(jù)收集器系統(tǒng)。

Grafana 是用于可視化大型測量數(shù)據(jù)的開源程序，使用 Go 語言開發(fā)，功能齊全，有著好看的儀表盤和圖表，可用來做日志的分析與展示曲線圖（如 API 的請求日志），支持多種 backend，如 ElasticSearch、InfluxDB、OpenTSDB 等等，最常用于網(wǎng)絡(luò)基礎(chǔ)設(shè)施和應(yīng)用分析，具有熱插拔控制面板和可擴展的數(shù)據(jù)源，

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

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

Vizceral 是 Netflix 發(fā)布的一個開源項目，用于近乎實時地監(jiān)控應(yīng)用程序和集群之間的網(wǎng)絡(luò)流量。

Vizceral 是一組采用 WebG 標準實現(xiàn)的動態(tài)展示線路圖組件，可以實現(xiàn)數(shù)據(jù)的查看以及交互，分為全局、部分區(qū)域、水平三個維度，使數(shù)據(jù)更為直觀明了的展示。

Vizceral 組件可以采取多個流量圖，并將生成一個“全局”圖，顯示所有傳入的流量到每個“區(qū)域”，支持跨區(qū)域通信。