DevOps專題 |監控，可觀測性與資料儲存

對於DevOps而言，監控是其中重要的一環，上一次的專題內容中，我們與大家分享了 大型企業級監控系統的設計。今天我們將和大家從另一個角度進一步探討網際網路工程技術領域的監控設計(monitoring)：系統的可觀測性(observerbality)。

無論監控，還是可觀測性，都是工程界的術語，並非嚴格定義的概念。人們可以描述它，但很難定義它。所以本文不會糾結於這些名詞之間的區別。

在實踐中，所有這些概念/術語，目標都是增強工程師對於線上系統執行情況的瞭解。

對工程師而言，監控/可觀測性工程存在的意義，是幫助工程師發現問題，定位問題，解決問題。

對系統自身而言，這些工作都是透過資料的採集/儲存/分析，以及進一步迭代來完成。

一、監控需求的產生

當程式被交付，部署到生產環境，才是其生命週期中最長的部分的開始。人們需要了解生產環境是否一切正常，監控需求自然而然產生。

網際網路發展過程中湧現大量監控相關的工具/系統，Ganlia, Zabbix, RRDTools, Graphite，各自在不同的層面為“是否正常”提供答案。

監控本身，無論是業界對監控的認知，監控工具/系統自身的能力，也在以下兩個方向演進著：

1. 黑盒到白盒
2. 資源到業務

這個階段監控的願景是很明確的，如何落地則各顯神通。

直到 Etsy 於 2011 年透過部落格公開了他們的 監控實踐，利用 StatsD（已開源），以非常簡單統一的方式，實現資源/業務層面的資料採集/儲存/分析。後來的監控系統，尤其是基於 metrics 的監控系統，大多受過 StatsD 的啟發和影響。

二、可觀測性的提出

網際網路工程界，Twitter 應該是最早提出可觀測性 的組織。在這系列文章中，Twitter 集中闡述了他們的可觀測性技術棧，其中包括了 Zipkin，Google Dapper 的開源實現。

如前言所說，本文不糾結於幾個名詞之間的包含關係。

拋開這些名詞的辯論，可觀測性相對於過去監控，最大的變化就是系統需要處理的資料，從 metrics 為主，擴充套件到了更廣的領域。綜合起來，大約有幾類資料被看作是可觀測性的支柱(pillar)

• metrics
• logging
• tracing
• events

因此，一個現代化的監控系統/可觀測性工程系統，也就必須具備妥善儲存以上幾種資料的能力。

三、儲存

Metrics

Metrics，通常是數值型別的時間序列資料。這類需求的存在如此廣泛，以至於衍生了專門服務於這個目標的資料庫子類，時間序列資料庫，TSDB。

TSDB 經歷了大約如下幾個方面的重要演進

• 資料模型。描述資訊從 metric naming 中剝離出來，形成 tag。現代的 tsdb 通常都已採用 tag 化的資料模型。
• 資料型別。從簡單的數值記錄，到為不同場景衍生出 gauge, counter, timer 等等更多的資料型別
• 索引結構。索引結構跟資料模型密切相關，在 tag 為主的現代 tsdb, 倒排索引已經是主流索引結構。
• 資料儲存。從 rrdtool 寫環形佇列到檔案的時代，到 OpenTSDB 這樣自行編解碼寫入底層資料庫，再到 Facebook 提出的時序資料壓縮演算法，通常會是若干種技術的綜合使用，並且針對不同的資料型別採用不同方案

Metrics 儲存，或者是 TSDB 的研究和演進，我們會有另外的文章專門介紹。

logging

logging 通常會是工程師定位生產環境問題最直接的手段。日誌的處理大約在如下幾個方面進行演進

• 集中儲存/檢索。使得工程師免於分別登陸機器檢視日誌之苦，日誌被統一採集，集中儲存於日誌服務，並提供統一的檢索服務。這個過程牽扯到例如日誌格式統一，解析，結構化等等問題。
• 日誌的監控。
• 原文中的關鍵字，例如 error, fatal 大機率意味著值得關注的錯誤產生
• 從日誌中提取的 metrics，例如 access log 中攜帶的大量資料，都可以被提取成有用的資訊。至於提取的手段，有的透過客戶端在日誌本地進行解析，有的在集中儲存過程中進行解析。

tracing

隨著網際網路工程日漸複雜，尤其是微服務的風潮下，分散式 tracing 通常是理解系統，定位系統故障的最重要手段。

在儲存層面，tracing 已經有相對明確的方案，無論是 OpenZipkin，還是 CNCF 的 Jaeger ，都提供幾乎開箱即用的後端軟體，其中當然包括儲存。

Tracing 的儲存設計主要考慮

1、稀疏資料：tracing 資料通常是稀疏的，這通常有幾個原因

• 不同業務的 trace 路徑通常不同，也就是 span 不同，因而稀疏
• 同種業務的 trace ，在不同內外部條件下，路徑也不同。例如訪問資料庫，是否命中快取，都會產生不同的 span 鏈
• 訪問正常/異常的 trace ，產生不同 span

2、多維度查詢：通常的解決思路

• 二級索引：在以 HBase, Cassandra 為基礎的方案中比較常見
• 引入倒排索引，在二級索引方案無法滿足全部查詢請求時，可能會引入 Elasticsearch 輔助索引，提升查詢靈活性

Events

同樣是一個難以定義，但是很容易描述的術語。我們把，一次部署，一次配置變更，一次dns 切換，諸如此類的變更，稱為事件。

它們通常意味著生產環境的變更。而故障，通常因為不恰當的變更引起。

對 events 的處理主要包括

• 集中儲存 ：事件種類很多，較難歸納共同的查詢緯度，所以倒排索引在這種無法事先確定查詢緯度的場景下，是非常合適的儲存結構
• Dashboard ： 以恰當的方式，把事件查詢 /展示出來。上文提到 Etsy 的部落格中，展示了很好的實踐方法，使得工程師能夠透過 dashboard ，非常輕鬆確認網站登陸失敗，與登入模組部署事件之間的關係。

總結

現代的監控，或者可觀測性工程，通常是對不同型別資料的採集/儲存/分析。這些資料各有特點，因而儲存也不存在銀彈。通常是根據各自特點，獨立設計儲存方案，上層提供一個統一、綜合的儲存系統。

京東雲監控具有實時展現監控資料變化及迅速報警等優勢，能夠滿足日常業務監控管理和處理異常等場景。