SRE:可觀察性:Metric命名空間與結構(二)

問題很關鍵

爲了幫助你們思考數據須要能回答什麼問題？在第一個例子裏數據不能回答「在全部實例裏每秒處理多少請求？」，但命名空間樹能夠。 客戶端庫提供命名空間能夠回答：全部客戶端生成的全部請求是多少？ 另一個常見的方法是經過命名空間客戶端度量消費服務的名稱而不是使用客戶端類庫自己。我發現對問題有用的是follow谷歌的黃金四指標 。

• 全部客戶端產生了多少請求？
• 每一個客戶端產生了多少請求？
• 每一個客戶端的每一個機器產生多少請求？
• 每一個機器，每一個RPC請求成功的比率是多少？

這個策略一樣適用於延遲，錯誤率，資源飽和狀況。

使用標籤的度量指標

我讀了datadog與prometheus的查詢與存儲的最佳實踐指南。想獲得一個宏觀視角並支持能下鑽到從上層命名空間到特定指標能夠使用tag和label(從宏觀開始到特定維度)，可是。。

當心基數

datadog與prometheus都推薦限制基數。

如下直接引用：

不要過分使用label
每個標籤都會對RAM,CPU,磁盤與網絡產生時間序列的損耗。一般能夠忽略不計，但在有不少指標與上百個標籤經過上百服務器的場景下，這會快速產生影響。

一個通用的指導原則，把你的指標限制在10個，對於超過的，想辦法在你的整個系統中限制他們。你的主要度量指標不該該有label。

若是你有一個指標有超過100的基數或可能成長到那個級別，調研下能限制維度的數量或將分析部分從監控系統移到一個通用處理系統。

能夠給你一個對下層數字更好的理解，讓咱們看下node_exporter. node_exporter從每一個對接的文件系統導出度量指標。每一個node都有巨量的時序數據寫入node_filesystem_avail，若是你有10000個node，你會爲node_filesystem_avail產生大約100000的時序數據，Prometheus能夠處理上面這些數據

若是你如今爲每一個用戶加配額，你會很快從10000個用戶在10000個node上達到翻倍的百萬級數字。這對於目前的Prometheus的實現來講太大了。就算是小一點的數量，還會有一個潛在的問題是你在這臺機器上不能使用其餘的更有用的度量。

若是你不肯定，能夠開始不使用標籤，稍後有具體場景時增長更多的標籤。

對於用戶級別的可觀察性通常能夠經過分佈式追蹤來解決。其有它本身的度量空間和最佳實踐。

結論

當結構化一個度量空間時最重要的是考慮數據能夠回答什麼問題。錯誤的結構可能致使回答問題更困難，或者根本答不出。雖然結構化度量空間不困難但要達到最大的效果須要頂層規劃。在應急場景時須要度量指標能進行擴展，由於須要看到全部的狀態及其狀態或維度，重要的是度量空間不會在開始階段就產生影響。

引用

• https://prometheus.io/docs/pr...
• https://prometheus.io/docs/pr...