架構

隨著分布式架構逐漸成為主流，“可觀測性”一詞也日益頻繁地被人提起，它涉及的范圍比較廣泛，主要概括為如下三類：

聚合度量（metrics）事件日志（logging）鏈路追蹤（tracing）

這三個方向雖然各有千秋，各有側重，但是又不完全獨立。在Peter Bourgon 的文章《Metrics, Tracing, and Logging》系統(tǒng)地闡述了這三者的定義、特征，以及它們之間的關系與差異，受到了業(yè)界的廣泛認可。

(相關資料圖)

在實際的工作中，大家或多或少對上面三種都有一定的了解，只是沒有機會或者沒有需求去深入研究。

聚合度量（Metrics）

度量是一種計量單位，它是指對系統(tǒng)中某一指標的統(tǒng)計聚合，然后通過聚合信息來揭示系統(tǒng)整體的運行狀況。

度量總體上可分為客戶端的指標收集、服務端的存儲查詢以及終端的監(jiān)控預警三個相對獨立的過程，每個過程一般都是不同的組件來完成，以Prometheus為例：

指標可以通過直接抓取各種exporters，也可以從pushgateway抓取，然后存儲在TSDB（時序數(shù)據(jù)庫）中，查詢指標可以通過grafana，也可以通過prometheus web，報警則是通過altermanager實現(xiàn)。

可以看到，一個度量工具的內(nèi)部實現(xiàn)是很復雜的，在使用的時候也會損耗一定的資源。

目前來說，在云原生領域中，Prometheus占據(jù)了很大的主導地位，嚴格來說，它已經(jīng)成云原生監(jiān)控的標配，下面我主要以Prometheus為例進行介紹。

指標收集

指標收集主要包括兩部分：

指標定義指標收集

相比于收集，指標定義尤為重要，良好的指標定義可以更直觀的反應系統(tǒng)狀態(tài)。

最常用的黃金指標有：

延遲：延遲是信息的發(fā)送方和接收方之間的時間延遲，以毫秒（ms）為單位。其原因通常是由于數(shù)據(jù)包丟失、網(wǎng)絡擁塞和稱為 “數(shù)據(jù)包延遲差異” 的網(wǎng)絡抖動。延遲直接影響客戶體驗，轉化為成功請求的延遲和失敗請求的延遲。流量：流量是系統(tǒng)上完成的工作量所帶來的壓力。它通過每秒查詢數(shù) (QPS) 或每秒事務數(shù) (TPS) 來衡量。企業(yè)通過數(shù)量來衡量這一點：關鍵績效指標 (KPI) 是在給定時間訪問網(wǎng)站的人數(shù)。這是與商業(yè)價值的直接關系。錯誤：錯誤是根據(jù)整個系統(tǒng)中發(fā)生的錯誤來衡量的。什么被視為服務錯誤率的重要指標！有兩類錯誤，顯式錯誤，例如失敗的 HTTP 請求（例如，500 個錯誤代碼）。而一個隱含的錯誤將是一個成功的響應，但與錯誤的內(nèi)容或響應時間長。飽和度：飽和度定義了服務的過載程度。它衡量系統(tǒng)利用率，強調資源和服務的整體能力。這通常適用于 CPU 使用率、內(nèi)存使用率、磁盤容量和每秒操作數(shù)等資源。儀表板和監(jiān)控告警是幫助您密切關注這些資源并幫助您在容量變得飽和之前主動調整容量的理想工具。利用率：雖然不是 “四大金信號” 的一部分，但值得一提；利用率告訴資源或系統(tǒng)有多忙。它以 %（百分比）表示，范圍為 0–100%。

所以在做指標定義的時候，可以結合以上的黃金指標進行分類，但是并不代表每一種類型的應用都需要滿足以上所有指標。以系統(tǒng)監(jiān)控為例，如下表示是否需要監(jiān)控該類指標：

定義好資源指標后，再來定義指標具體的獲取方法。

目前，基于Prometheus監(jiān)控所實現(xiàn)的Exporter非常多，這些Exporter基本能夠拿到我們想要的指標，比如：

指標查詢

指標收集到Prometheus之后，會存儲到它的TSDB（時序數(shù)據(jù)庫）中，我們可以在Prometheus Web中查詢需要的指標，如下獲取不同時間節(jié)點kubelet的HTTP請求總數(shù)：

監(jiān)控預警

指標度量是手段，最終目的是做分析和預警。

我們可以通過這些指標制作監(jiān)控大屏，隨時觀察系統(tǒng)的狀態(tài)，如下可以實時監(jiān)控Kubernetes中容器以及節(jié)點的狀態(tài)：

良好的可視化能力對于提升度量系統(tǒng)的產(chǎn)品力十分重要，長期趨勢分析（譬如根據(jù)對磁盤增長趨勢的觀察判斷什么時候需要擴容）、對照分析（譬如版本升級后對比新舊版本的性能、資源消耗等方面的差異）、故障分析（不僅從日志、追蹤自底向上可以分析故障，高維度的度量指標也可能自頂向下尋找到問題的端倪）等分析工作，既需要度量指標的持續(xù)收集、統(tǒng)計，往往還需要對數(shù)據(jù)進行可視化，才能讓人更容易地從數(shù)據(jù)中挖掘規(guī)律。

還可以對重要的指標進行告警，以便維護人員能夠及時地介入排查問題，如下是一個應用JVM使用過載的告警。

但是，在做告警的時候需要綜合考慮指標的重要程度，不是所有指標都需要告警，不然就容易造成告警風暴，最后就會真實演繹《狼來了》的故事。

事件日志（Logging）

日志用來記錄系統(tǒng)運行期間所發(fā)生的事件，每個系統(tǒng)都應該有日志。

日志是排查問題的重要手段，大部分系統(tǒng)問題最終都會追溯到日志上，所以良好的日志記錄有助于快速定位系統(tǒng)問題。

但是，目前基本都是微服務多節(jié)點的形式存在，沒辦法像單機時代那樣簡單使用命令就能獲取到日志內(nèi)容。而是需要把日志收集到專門的日志系統(tǒng)，然后再進行查詢、分析等。

目前比較受歡迎的開源日志系統(tǒng)是ELK或者EFK，它在日志領域有著不可撼動的地位。

事件日志也涉及以下幾個方面：

日志輸出日志收集日志查詢?nèi)罩靖婢罩据敵?p>一千個開發(fā)可能有一千個日志輸出方式，而且輸出的內(nèi)容千奇百怪，不管重要的或者不重要的都輸出到日志里，這將會導致日志查看困難，干擾大。

所以，良好的日志記錄習慣是非常重要的，在企業(yè)中應該有專門的日志規(guī)范，這樣可以統(tǒng)一格式、統(tǒng)一標準，不僅有助于收集，也有助于查看。

打印日志應該盡量做到以下幾點：

記錄請求的TraceID記錄關鍵事件，包括上下文不要打印敏感信息合理規(guī)劃日志級別日志收集

對于分布式服務，為了能同時看到跨節(jié)點的全部日志，就需要把各種日志統(tǒng)一收集，比如使用Logstash或者Filebeat來收集日志，在日志收集的同時還可以對日志進行處理，比如同一個應用的日志可以建一條索引，同一個應用的索引可以按天進行創(chuàng)建等，這樣避免索引過大導致查詢困難等問題。

如果在日志收集的過程中發(fā)現(xiàn)日志比較大，可以在收集處理的過程中先把日志寫入緩存或者消息隊列，避免直接寫入Elasticsearch導致其壓力過載。

日志查詢

收集到的日志最終是存儲在Elasticsearch中，它通常搭配Kibana一起使用，方便用戶操作。

Kibana 盡管只負責圖形界面和展示，但它提供的能力遠不止讓你能在界面上執(zhí)行 Elasticsearch 的查詢那么簡單。Kibana 宣傳的核心能力是“探索數(shù)據(jù)并可視化”，即把存儲在 Elasticsearch 中的數(shù)據(jù)被檢索、聚合、統(tǒng)計后，定制形成各種圖形、表格、指標、統(tǒng)計，以此觀察系統(tǒng)的運行狀態(tài)，找出日志事件中潛藏的規(guī)律和隱患。按 Kibana 官方的宣傳語來說就是“一張圖片勝過千萬行日志”。

日志告警

在做日志輸出的時候，對于一些有破壞性的日志需要特別標記，當遇到這類日志就需要及時的通知維護人員。我們可以使用ElastAlert來進行告警處理。

ElastAlert是三方插件，通過查詢 ElasticSearch 中的記錄進行比對，通過配置報警規(guī)則對匹配規(guī)則的日志進行警報。 ElastAlert 將Elasticsearch與兩種類型的組件（規(guī)則類型和警報）結合使用，定期查詢Elasticsearch，并將數(shù)據(jù)傳遞到規(guī)則類型，該規(guī)則類型確定何時找到匹配項。發(fā)生匹配時，將為該警報提供一個或多個警報，這些警報將根據(jù)匹配采取行動。

鏈路追蹤（Tracing）

有了度量和日志，在多數(shù)情況下已經(jīng)能滿足日常使用，但是它們有一個弊端，就是沒辦法很直觀的查看上下文，也無法有效的追蹤某個請求。

所以，就引入了鏈路追蹤。

從目標來看，鏈路追蹤的目的是為排查故障和分析性能提供數(shù)據(jù)支持，系統(tǒng)對外提供服務的過程中，持續(xù)地接受請求并處理響應，同時持續(xù)地生成 Trace，按次序整理好 Trace 中每一個 Span 所記錄的調用關系，便能繪制出一幅系統(tǒng)的服務調用拓撲圖。根據(jù)拓撲圖中 Span 記錄的時間信息和響應結果（正?；虍惓７祷兀┚涂梢远ㄎ坏骄徛蛘叱鲥e的服務；將 Trace 與歷史記錄進行對比統(tǒng)計，就可以從系統(tǒng)整體層面分析服務性能，定位性能優(yōu)化的目標。

從字面上看鏈路監(jiān)控的實現(xiàn)方式比較簡單，然而在實際工作中卻比較復雜。主要在于企業(yè)業(yè)務系統(tǒng)可能采用不同的程序語言 ，每一種程序語言實現(xiàn)的方式都不一樣，這就導致工作量非常巨大，而且還要考慮以下幾點：

低損耗：如果接入鏈路監(jiān)控不僅沒有解決問題，反而加大了性能開銷，這就得不償失。透明：盡量在不加大開發(fā)工作量，最好能做到無侵入接入。易用：傻瓜式的使用方式比較受歡迎。

目前最常用的是Zipkin、Skywalking、Pinpoint等，它們都是基于服務追蹤實現(xiàn)的。

服務追蹤的實現(xiàn)思路是通過某些手段給目標應用注入追蹤探針（Probe），針對 Java 應用一般就是通過 Java Agent 注入的。探針在結構上可視為一個寄生在目標服務身上的小型微服務系統(tǒng)，它一般會有自己專用的服務注冊、心跳檢測等功能，有專門的數(shù)據(jù)收集協(xié)議，把從目標系統(tǒng)中監(jiān)控得到的服務調用信息，通過另一次獨立的 HTTP 或者 RPC 請求發(fā)送給追蹤系統(tǒng)。

下面是使用Skywalking收集之后的查詢頁面。

最后

可觀測性平臺是一個很大很復雜的平臺，大部門公司都是用一些開源手段來堆疊，雖然能解決一些問題，但是它們各自是相互獨立的，沒辦法很友好的進行關聯(lián)。這也導致在排查問題的時候需要各個平臺來回切換，而且每個平臺都需要一定的學習成本，這也導致許多公司安裝部署了，但是實際很少去用，沒有發(fā)揮其要實現(xiàn)的效果。

鏈接

【1】https://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html【2】https://skywalking.apache.org/【3】https://www.elastic.co/cn/

關鍵詞： 可觀測性 觀察系統(tǒng) 以下幾點