原文： https://medium.com/dm03514-tech-blog/sre-observability-metric-namespaces-and-structures-12ffcf5a5bdc
結構化的metric命名空間對于需要快速擷取資訊的故障場景非常重要。為了能支援廣泛的查詢和擴充場景，需要仔細考慮metric名稱和次元。我發現其中一種為靈活metric模組化的方式就是将他們認為是樹。将metric想象成樹可以有以下好處：檢視特定子集的資料，根據其子集定義度量基準與設定門檻值。這些度量命名空間的屬性可以進一步回答更多具體的問題并可以下鑽到資料的子集并像看度量名額一樣觀察度量名額的組成部分。這些概念很熟悉，因為他們是想Prometheus與DogStatsD這種雲原生監控解決方案的第一級想法。
什麼
度量空間是概念意義上的度量名額活着的空間。他們的邊界通常是一個資料庫或一個賬号：
度量空間不隻是度量名額存活的地方，也包含度量空間的結構。正确的命名與結構可以有很大的好處。以上圖的度量命名空間沒有明顯的結構。每個度量名額都是浮在這個空間上的。他們除了表示他們存在相同的度量空間中外，沒有任何其他内容。在沒有結構化的設定裡每個度量名額都要單獨使用。如果要看一個服務的http請求的頻率需要直接單獨通路 service_N_http_requests_total。
假設看到請求通過服務所有執行個體的總量很有用。在以下的例子中如果建了一個新服務會怎麼樣？
如果加和是在service_1和service_2計算的，當增加service_3時，他們之間沒有什麼聯系；沒有可度量的結構。請求總數沒有反應真實的請求總量，隻有service_3_http_requests_total被手工加上去後才行。下圖表示了這個過程：
度量樹
一個對于無結構空間的可用方式是用metric命名空間組成一種顯式的結構，以下圖示說明了這種樹的結構：
在Prometheus和Datadog度量結構可以使用Label和tags建立。使用tag，可以動态擴充總請求量；當一個新的service增加時，他可以通過樹指向到主度量名額。
在prometheus，得到通過所有服務的每秒的頻率可以看下圖：
通過結構化的命名空間可以動态計算通過樹根節點的總量（在這個例子計算了每個單獨服務作為一個度量名額）。
用它的子名額來定義度量名額
用一個樹，每一個度量的次元(比如"service"标簽)包含了節點獨立的請求頻率。使用一個度量命名空間，不隻是它的總頻率可以觀察，每個子服務執行個體都可以被可視化：
對命名空間的資料模組化，可以通過對所選次元的組合來組合父資料。
增加資料的子集
命名空間也支援将資料的特定子集的明細。樹可以回答這種問題： 在灰階機器上所有成功http請求的p99(譯者: p99, p95都是術語，p99表示過去的10秒内最慢的1%請求)延遲是多少？
上面這個樹對概念空間進行了模組化同時沒有對度量名額如何存儲在磁盤上模組化。使用一種良好定義的度量空間可以對任何次元進行擴充。
以下圖展示了這個樹的p99與p50的圖形化：
通過以上技術可以拿到任意度量次元更具體的資料： 在灰階部署的每一個機器上所有成功http請求的p99延遲是多少？
以下展示了prometheus對于擴充這個機器名額machine_id的支援：
由于這個名額在頂層名額上有結構化的定義是以可以使用machine_id進行動态擴充。
比例(Ratio)規則
比例是另一種在一個非結構化空間中将資料建立聯系的方式。這十分有用，并且是由于google SRE而備受歡迎的計算SLO可用率與錯誤率的基礎。 比例讓使用者可以顯式的關聯名額，完成一個度量名額結構。這些連接配接經常被表示為百分比，例如可用性可以被計算成 成功請求數/總請求書，而錯誤率可以計算成錯誤請求數/總請求數。其他重要的比率是多種狀态中的一種狀态出現了多少。
為了解釋這個，我們假設一個應用執行的一個請求可以産生多種狀态，例如 cache_hit:true與cache_miss:false。要看緩存的命中率我們按如下方式結構化資料：
這個圖示示了緩存命中率與失敗率的例子。每個請求要麼命中要麼失敗。而每秒大約有160個請求：
下圖關聯了總請求頻率與緩存命中頻率，展示了50%的緩存命中率：
這建立了一種邏輯關
系，而他麼不是直接或者有具體關系的，在datadog與prometheus可以表示為算術運算。用這種方式在查詢級别任何兩種度量都可以被關聯上。