DevOps專題 |監控，可觀測性與數據存儲

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

不管監控，仍是可觀測性，都是工程界的術語，並不是嚴格定義的概念。人們能夠描述它，但很難定義它。因此本文不會糾結於這些名詞之間的區別。

在實踐中，全部這些概念/術語，目標都是加強工程師對於線上系統運行狀況的瞭解。

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

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

1、監控需求的產生

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

互聯網發展過程當中涌現大量監控相關的工具/系統，Ganlia, Zabbix, RRDTools, Graphite，各自在不一樣的層面爲「是否正常」提供答案。

監控自己，不管是業界對監控的認知，監控工具/系統自身的能力，也在如下兩個方向演進着：

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

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

直到 Etsy 於 2011 年經過博客公開了他們的 監控實踐，利用 StatsD（已開源），以很是簡單統一的方式，實現資源/業務層面的數據採集/存儲/分析。後來的監控系統，尤爲是基於 metrics 的監控系統，大多受過 StatsD 的啓發和影響。

2、可觀測性的提出

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

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

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

• metrics
• logging
• tracing
• events

所以，一個現代化的監控系統/可觀測性工程系統，也就必須具有妥善存儲以上幾種數據的能力。

3、存儲

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 的存儲設計主要考慮

一、稀疏數據：tracing 數據一般是稀疏的，這一般有幾個緣由

• 不一樣業務的 trace 路徑一般不一樣，也就是 span 不一樣，於是稀疏
• 同種業務的 trace，在不一樣內外部條件下，路徑也不一樣。例如訪問數據庫，是否命中緩存，都會產生不一樣的 span 鏈
• 訪問正常/異常的 trace ，產生不一樣span

二、多維度查詢：一般的解決思路

• 二級索引：在以 HBase, Cassandra 爲基礎的方案中比較常見
• 引入倒排索引，在二級索引方案沒法知足所有查詢請求時，可能會引入Elasticsearch 輔助索引，提高查詢靈活性

Events

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

它們一般意味着生產環境的變動。而故障，一般由於不恰當的變動引發。

對 events 的處理主要包括

• 集中存儲：事件種類不少，較難概括共同的查詢緯度，因此倒排索引在這種沒法事先肯定查詢緯度的場景下，是很是合適的存儲結構
• Dashboard：以恰當的方式，把事件查詢 /展現出來。上文提到 Etsy 的博客中，展現了很好的實踐方法，使得工程師可以經過 dashboard，很是輕鬆確認網站登錄失敗，與登陸模塊部署事件之間的關係。

總結

現代的監控，或者可觀測性工程，一般是對不一樣類型數據的採集/存儲/分析。這些數據各有特色，於是存儲也不存在銀彈。一般是根據各自特色，獨立設計存儲方案，上層提供一個統1、綜合的存儲系統。

京東雲監控具備實時展示監控數據變化及迅速報警等優點，可以知足平常業務監控管理和處理異常等場景。

目前京東雲監控提供免費服務，點擊【閱讀】，瞭解更多關於京東雲監控的內容。

歡迎點擊「京東雲」瞭解更多精彩內容