一文詳解阿里雲可觀測體系下標籤最佳實踐

作者：陽其凱（逸陵）

在當今數字化轉型加速的時代，企業 IT 系統的複雜度與日俱增，如何高效地管理和監控這些系統成為了一項挑戰。阿里雲作為全球領先的雲端計算服務商，提供了一整套全面的可觀測性解決方案，覆蓋從業務、端側（小程式、APP、H5 等）、應用、中介軟體、容器/ECS 等全棧的監控體系，旨在幫助企業構建強大而靈活的可觀測性體系。其中，標籤（Tag）作為一種核心組織和管理手段，在阿里雲可觀測體系中扮演著至關重要的角色。本文將深入探討阿里雲可觀測系列產品中標籤的應用，以及如何運用標籤在阿里雲可觀測產品體系下進行體系化建設並給出相關最佳實踐。

標籤的基礎與價值

1.1 什麼是標籤

標籤是一種後設資料（Meta），用於附加到雲資源上，是一些充當後設資料的詞和短語，以實現資源的分類、管理和過濾。標籤（Key:Value）由標籤鍵和標籤值進行組成：

標籤鍵（Key）：標籤管理中用於定義一個分類的值，多由使用者定義來代表不同的業務分類。
標籤值（Value）：標籤鍵下一系列描述性屬性，多用來陳述一個標籤鍵代表的型別下都有哪些選項。

那麼這裡有一個問題需要重點關注，那就是阿里雲的標籤為啥是鍵值對的形式？業界也有部分的產品/系統採用的是單值的形式，帶著疑問我們繼續往下。

1.2 阿里雲標籤分類

阿里雲標籤 [ 1] 分為如下幾個類別：自定義標籤、系統標籤、建立者標籤、預置標籤。

自定義標籤： 是由使用者自己建立的，由使用者進行定義以及維護，靈活性非常高；建立自定義標籤，必須同時繫結資源。單次最多可以建立 10 個標籤，並且標籤鍵不可重複。如果需要僅建立標籤，並規劃標籤鍵和值，需要使用預置標籤。自定義標籤也是本篇文章核心關注的內容。
系統標籤： 系統標籤是由系統自動產生，通常以一種相對標準化的形式呈現資料關係的一種標籤。在一些固化場景下，使用者可以藉助系統標籤來輔助業務使用。系統標籤可以對使用者可見，但是不支援使用者建立或刪除。只有雲產品可以建立系統 TAG，系統 Tag 必須以 acs: 開頭。如下所示為：

建立者標籤： 使用者在建立資源時，系統會預設為資源打上一個建立者標籤（createdby 標籤）。建立者標籤是系統標籤，對使用者可見。建立者標籤可以幫助使用者分析費用和賬單，實現企業雲上成本管理,還可以幫助使用者進行建立者資訊溯源，提升資源管理便利性。
預置標籤： 預置標籤是指預先建立並作用於所有地域的一種標籤，非常適合在標籤規劃階段使用。使用者可以在標籤規劃階段建立預置標籤，然後在標籤實施階段繫結具體的雲資源。

1.3 阿里雲標籤的通用價值

阿里雲全球基礎設施都需要支援標籤，標籤是阿里雲整體資源分組能力，而不是單個產品的分組能力，標籤體系能力全面提升了阿里雲生態能力，透過標籤，使用者可以基於業務場景、環境、成本中心等維度對資源進行邏輯分組，進而實現精細化管理和監控。

從管理層面，可以基於標籤做分組訪問控制；分組審計；分組安全管理；方便從全域性搜尋。
從運維層面，可以基於標籤做客戶側主動運維，分組監控報警診斷，分組訊息，動態縮擴容。
從財務層面，可以基於標籤做多維度分賬管理、自定義賬單檢視、多維度成本分析。
從部署層面，可以基於標籤來做資源編排。
從設計層面，可以基於標籤規劃成本、規劃資源整體能力，以及阿里雲全域性產品概覽視角。

1.4 阿里雲可觀測體系下的標籤價值

在阿里雲可觀測體系下，合理利用標籤能夠帶來以下幾大價值：

資源組織與發現：標籤使資源易於搜尋和分類，幫助運維人員快速定位和管理相關資源。
成本分析與最佳化：結合阿里雲的成本管理服務，標籤可輔助進行資源消耗的細粒度分析，支援成本控制和最佳化。
自動化與策略實施：標籤是自動化規則和策略執行的關鍵依據，比如基於標籤的報警策略或自動擴充套件規則。
合規性與安全管理：透過標籤標識資源的敏感性和合規要求，支援安全策略的實施和審計。

阿里雲可觀測體系標籤的應用

2.1 可觀測資源管理

標籤是在阿里雲管理控制檯中整理阿里雲資源的好方法，使用者可以配置標籤來與資源一起顯示。目前在阿里雲可觀測產品家族常見的功能主要表現為資源搜尋以及資源許可權控制。

2.1.1 可觀測資源分類/搜尋

標籤是在阿里雲管理控制檯中整理阿里雲資源的絕佳方法。您可以配置標籤來與資源一起顯示，並且可以按標籤進行搜尋和篩選。當前可觀測產品家族中日誌服務、阿里雲 ARMS（體驗監控、應用監控、Prometheus 例項、Grafana 例項、報警規則）等已經全面支援資源組或者自定義標籤。常見資源管理方式如下：

方式1： 基於阿里雲可觀測控制檯進行標籤的資源搜尋，以阿里雲 Prometheus 和 ARMS 應用監控為例，如下為基於標籤進行 Prometheus 例項資源的篩選。

如下為基於標籤進行 ARMS 應用監控例項資源的篩選。

方式2： 在阿里雲資源編排 ROS [ 2] 堆疊中的基於標籤篩選您的資源，該部分這裡暫時不進行擴充套件。

2.1.2 可觀測資源許可權管控

訪問控制 RAM 策略支援基於標籤的條件，使您能夠根據特定標籤或標籤值約束訪問控制 RAM 許可權，可觀測產品族同樣支援該特性，以 ARMS 應用監控為例 [ 3] ：如下需要設定杭州地域標籤為 key0: value01 或 key0: value02 應用的只讀許可權。

{
  "Version": "1",
  "Statement": [
    {
      "Action": [
        "arms:ReadTraceApp"
      ],
      "Resource": "acs:arms:cn-hangzhou:*:armsapp/*",
      "Effect": "Allow",
      "Condition": {
        "StringEquals": {
          "arms:tag/key0":[
            "value01",
            "value02"
          ]
        }
      }
    }
  ]
}

上述 policy 進行簡單說明：

1）效果（Effect） ：授權效果包含允許（Allow）和拒絕（Deny），本案例中設定為Allow。

2）操作（Action） ：ARMS 應用監控相關 Action 詳細參考文件 [ 4] ，本案例中為應用監控的的只讀許可權 arms:ReadTraceApp。

3）資源（Resource） ：用於指定被授權的具體物件，格式如下：

"Resource": [
     "acs:arms:<regionid>:*:armsapp/<appname>"
 ]

4）條件（Condition） ：條件塊（Condition Block）由一個或多個條件子句構成。一個條件子句由條件操作型別、條件關鍵字和條件值組成。ARMS 應用監控支援透過標籤鍵值對指定被授權的物件。

標籤鍵值對支援的條件操作型別：
- StringEquals
- StringNotEquals
- StringEqualsIgnoreCase
- StringNotEqualsIgnoreCase
- StringLike
- StringNotLike
條件關鍵字：arms:tag。
條件關鍵值：標籤鍵值對。

本案例對標籤鍵值對等於 key0: value01 或 key0: value02 的應用授權。

"Condition": {
  "StringEquals": {       //條件操作型別。
    "arms:tag/key0":[      //條件關鍵字
      "value01",        //條件關鍵值
      "value02"
    ]
  }
}

關於自定義策略的配置在這裡不進行過多的闡述，總之，基於標籤的自定義許可權策略有助於實現可觀測資源許可權的精細化管控，是提升資源訪問安全的有效手段。

2.2 監控資料富化

2.2.1 體驗監控資料富化

使用者在接入 ARMS 體驗監控後會產生兩種型別的資料，指標型別的資料以及明細資料。

指標型別的資料當前儲存到對應區域的 Prometheus 例項中，以國內為例，對應的 Prometheus 例項名稱為 rum-cn-hangzhou。
明細型別的資料儲存在使用者名稱下的阿里雲日誌服務 SLS 中，對應的 logstore 為 logstore-rum，透過列表中“查詢日誌”的入口可以直接跳轉到 SLS 中。

在 ARMS 體驗監控 APP 上打上相關的標籤，體驗監控的指標資料以及明細資料會自動帶上相關的標籤， 如下例項將某一個體驗監控 APP 打上 department=IOT 運營平臺，其指標如下所示：

對對應的明細資料如下：

2.2.2 應用監控資料富化

目前 ARMS 應用監控提供兩種維度的標籤：應用標籤和例項標籤，請您根據使用場景選擇合適的標籤型別，詳細參考如下文件。

2.2.2.1 應用標籤

作用於 ARMS 應用上，您可以在 ARMS 控制檯應用監控 > 應用列表頁面檢視或修改應用標籤，如下截圖我們針對一個特定的應用打上自定義標籤 Company=阿里巴巴以及 app=xx-cn-hangzhou-pre。

等待 1 分鐘左右即可在該應用的指標中查詢到對應的 label。

2.2.2.2 例項標籤

在 ARMS 的設計中，一個應用可以包含多個應用例項，每個應用例項都代表一個 Java 程序，它們透過相同的應用名接入到 ARMS 中。不同於應用標籤，例項標籤作用在應用例項上，對於同屬一個應用的不同應用例項，它們可以擁有不同的例項標籤。

對於 Kubernetes 環境下自動接入 ARMS 應用監控的應用例項，ARMS 會預設寫入如下例項標籤：

除了預設例項標籤外，您還可以新增自定義例項標籤。同時，例項標籤還會完整地繼承應用標籤，ARMS 為應用例項產生的監控資料中，都會帶上對應的例項標籤。

如下圖所示，應用 my-app 包含兩個例項，ARMS 為例項 B 生成的指標資料 arms_jvm_gc_total 中包含的標籤為：

{env: Dev, team: Observability, app: my-app, workloadKind: Deployment, workloadName: my-app, clusterName: ClusterA, namespace: nsA, gitVersion: 1.0.2}

例項標籤常用的應用場景：灰度釋出對比

例如一個應用中包含多個例項，在進行應用釋出的時候將部分例項設定為灰度標，將釋出例項與未釋出例項進行對比，進而輔助觀測判斷服務的釋出狀況。

2.2.3 雲服務監控資料富化

可觀測監控 Prometheus 版在透過企業雲監控接入雲服務監控指標時，支援在雲監控本身標籤的基礎上，將例項的後設資料（例如例項 ID 或例項標籤）作為指標的標籤富化到該例項相關的監控指標上。有以下兩種場景：一種是預設寫入通用標籤，另一種是您可以自定義將例項上的 Tag 作為標籤寫入指標。

2.2.3.1 通用標籤

具體的標籤會依據雲產品的型別而有所不同，因此 Prometheus 在收集指標過程中，會把例項相關的其他後設資料資訊以標籤形式附加至相應指標上。

2.2.3.2 自定義標籤

雲產品例項上帶有 o11y.aliyun.dev/ 字首的標籤也將被包含在指標資料中。例如，若例項標籤是 o11y.aliyun.dev/project=abc，則會在監控指標裡會增加一個新的標籤 project=abc。如下以 ECS 為例：

1）如下的 ECS 例項打上了自定投標籤 o11y.aliyun.dev/department=IT 資訊中心。

2）登入進入 ARMS 控制檯 [ 5] ，在左側導航欄單擊接入中心，在接入中心頁面，然後單擊阿里雲 ECS，按照相關說明正常接入即可，詳細參考：https://help.aliyun.com/zh/arms/prometheus-monitoring/getting...

3）進入共享版的 Grafana 進行資料的 explore，Expore 頁面中選擇雲服務對應的資料來源，比如查詢 AliyunEcs_load_1m 指標。

2.2.3.3 支援情況說明

目前接入中心中大部分雲產品已經支援標籤富化的能力，比如常見的 ECS、RDS、Redis、EIP、SLB、ALB、NLB、ElasticSearch、PolarDB、RocketMQ 等，如雲原生閘道器/註冊中心、DDOS、WAF 等正在支援中，如果有需求可以提工單聯絡值班同學。

2.3 雲監控應用分組

應用分組提供跨雲產品、跨地域的雲產品資源分組管理功能，支援使用者從業務角度集中管理業務線涉及到的伺服器、資料庫、負載均衡、儲存等資源。從而按業務線來管理報警規則、檢視監控資料，迅速提升運維效率。而標籤能力在資源的選擇與組織上扮演了重要的角色，如下為使用“標籤”建立應用分組。

2.4 告警事件富化

告警事件富化常見的幾種如下：

2.4.1 頁面設定標籤

支援說明： 當前體驗監控、應用監控、Prometheus 監控、雲監控、日誌服務支援針對告警規則設定標籤（雲監控定時撥測暫時不支援，敬請期待），設定的標籤會自動透出對應的告警事件中。

功能/案例演示： 如下為應用監控告警規則設定。

2.4.2 動態標籤

支援說明： 該場景暫時僅 Prometheus 告警、SLS 告警 [ 6] 支援動態標籤，ARMS 體驗監控、ARMS應用監控、雲監控告警等暫時不支援，但是 ARMS 體驗監控、ARMS 應用監控可以利用 Prometheus 告警進行實現。

功能/案例演示： 利用該功能可以根據特定的條件，動態設定標籤，比如根據我們配置一個 ECS CPU 報警，我們希望這些報警事件帶上該 ECS 歸屬的 ACK 例項 ID，詳細參考文件 [ 7] 。

1）ECS 控制檯中可以看到 ECS 例項會帶上 ack.aliyun.com 的標籤。

2）在 ARMS 控制檯的 Prometheus 監控 > Prometheus 告警規則進行 Prometheus 告警的設定，告警名稱為 ECS CPU 使用率大於 75% ，檢測型別為自定義 PromQL，自定義 PromQL 語句設定為 arms_cms_ecs_cpu_total > 75，其他告警引數的配置，請參見 Prometheus 告警規則 [ 8] 。

3）告警中使用註釋對告警進行打標，由於 Prometheus 不支援標籤的 Key 中包含半形句號（.），因此此處透過 label_replace 對標籤進行重新命名，重新命名為 clusterId。

鍵：_aliyun_arms_enrich_desc。
值：可執行的 PromQL，支援透過 ${xxx} 引用告警中的標籤，此處示例為 sum(label_replace(aliyun_arms_tag{id=${id}, key="ack.aliyun.com", service="ecs"}, "clusterId", "$1", "value", "(.*)")) by (clusterId)，示例中使用了 ${id} 來引用 ECS 的 ID。

4）結果：告警事件中會增加 clusterId 的標籤。

擴充套件案例：透過 Kubernetes Label 分發告警 [ 9]

2.4.3 事件處理流

在告警運維中心 [ 10] 中我們可以利用事件處理流中相關功能可以達到富化的效果。

欄位豐富：該功能依賴外部 API 資料來源或者本地 Local 靜態配置（excel 靜態資料），透過資料來源進行資料的關聯進而達到欄位豐富的效果。

分割內容：比如某自研告警系統中所有的主機都使用固定格式進行命名，命名格式為 ${env}-${biz}-${app}-${group}-${index} ，需要提取其中的 biz 欄位作為業務標籤。配置正確的觸發條件後，使用分割內容操作，將 hostname 根據字元'-'進行分割，分割後的內容依次填充到 env、service、 app、group 欄位。

設定業務標籤：某xx業務使用了自研監控系統，透過自定義整合將自研的告警接入到 ARMS 告警管理中後，需要對這部分告警統一打上業務標籤xx。

可觀測標籤推薦最佳設計

為了最大化可觀測標籤的價值，建議遵循以下標籤設計原則。

3.1 命名標準化原則

標籤始終使用標準化、區分大小寫的格式，為了相容各個雲產品大小寫支援差異，建議全部使用小寫。
可觀測中相關指標資料儲存在 Prometheus 中，所以標籤的 Key 建議滿足 Prometheus 命名規範， 即符合正則規則：^a-zA-Z_*$。
acs: 字首專門預留供阿里雲使用。 當標籤具有帶 acs: 字首的標籤鍵時，您將無法編輯或刪除標籤的鍵或值，對於自定義的標籤建議不要使用與 acs 類似的字首。

3.2 互斥/集體詳盡的原則

儘量避免在同一個屬性上使用兩個相似語義標籤鍵，比如歸屬者用 key="owner" 表示，就最好不要有表示同一個含義的鍵，比如 own、Belonger、歸屬者等。
所有資源都必須繫結已規劃的標籤鍵及其對應的標籤值。例如：某公司有 3 個遊戲專案部，標籤鍵是 project，則應至少有 3 個標籤值分別代表這 3 個專案部。集體詳盡原則是後續基於標籤維度進行資源檢索、分賬、自動化運維和訪問控制的必要條件。

3.3 有限值原則

只保留核心標籤值，刪除多餘的標籤值。

3.4 簡化設計原則

設計標籤時使用固定的標籤，簡化標籤的使用，標籤的設計儘量簡化 key 和 value 的值， 滿足業務訴求即可。

3.5 考慮未來變化原則

設計標籤時要考慮後續工作中增加或者減少標籤值的影響，儘可能將業務邊界劃分得更加清晰一點， 提高標籤修改的靈活性。例如：企業在上雲初期業務比較集中，就採用部門標籤 department 來管理部門相關的資源歸屬、財務歸屬和自動化運維。隨著企業的發展，這一個標籤已經承載了一些日常業務，想要區分開就需要耗費一定成本。因此，我們建議，企業在上雲初期需要先評估標籤的業務訴求，如在上述例子中則需規劃同時採用 department、costcenter 和 ops 標籤。

阿里雲可觀測體系下標籤實踐案例

4.1 基於標籤體系的穩定性大盤建設

4.1.1 客戶背景

客戶為某著名奶茶行業客戶（以下簡稱 cha），當前客戶 cha 正處於業務飛速發展的階段，底層基礎設施不完善，前期阿里雲可觀測產品 ARMS 以及 Prometheus 都已經接入了，但是沒有被很好的使用，客戶在使用的階段存在如下迫切的訴求。

當前 cha 體系在的系統/資源分佈在不同的區域，主要集中在國內上海以及海外新加坡，各個系統/資源區分測試、預發、生產等，且這些系統/資源歸屬不同的業務線，如B端業務線和 C 端業務線，其中B端業務包含線下開店流程、物料採購、閉店打烊等管理系統等，C 端業務如奶茶加購、下單、支付系統等，CTO、架構師希望有針對地域、環境、業務線、專案等的全域性穩定性大盤；
運維部門希望對各個區域、環境、部門的應用/資源進行盤點，進行統一的資源監控與分析；

4.1.2 建設思想

核心理念：分層設計、標籤驅動。

4.1.2.1 分層設計

如下以 cha 中 B 端的業務架構，是一個比較典型的電商微服架構體系。最上層為使用者業務的端側，主要包含 PC 端、小程式（微信、支付寶等）、App（安卓、IOS），端側承載了使用者的 toB 的業務入口，流量首先會經過阿里雲 DDOS 以及 WAF，閘道器層面使用了 CLB 以及自建的 Gateway，下面為部署在 SAE/阿里雲 ACK 的微服務應用，中間微服務之間的依賴呼叫關係這裡不進行展開，同時底層依賴了常用的中介軟體、資料庫、儲存等。

全域性穩定性我們採用分層設計的理念，按照端側、閘道器、應用、中介軟體、ECS/容器層等進行分層至上而下進行設計，同時輔助上層業務或者整體 SLO 作為概覽。

4.1.2.1 標籤驅動

標籤驅動的核心理念還是圍繞指標、日誌、事件進行富化，將標籤加入到指標（日誌、事件）的 label 中，在大盤中利用標籤串聯多個 panel， 達到集級聯的效果。

4.1.3 建設方案

4.1.3.1 規劃標籤體系

客戶cha目前公司系統採用如下的組織形式，最上層按照業務線維度進行區分，不同的業務線下有相關的專案，專案下有不同的雲資源，雲資源區分割槽域（上海、新加坡）以及開發環境（dev、pre、prod 等）。

按照上面標籤的設計原則，客戶定義瞭如下的標籤，下面僅給出設計參考

這裡針對雲服務的標籤需要明確一下：如果雲服務採用上面形式的標籤，預設指標中不會帶上自定義標籤，需要在接入的時候手工將自定義的標籤加入白名單，否則採用 o11y.aliyun.dev/ 字首的標籤，這裡建議採用通用的非字首標籤形式，方便標籤的統一。

4.1.3.2 建立標籤關係

標籤關係的建立目前主要分為手工頁面配置方式以及 API 方式。

手工頁面方式：進入到各個雲產品控制檯以及可觀測控制檯中體驗監控、應用監控等模組，手工將對應的標打上即可；
API 方式：可以使用阿里雲標籤服務的介面 TagResources [ 11] 完成打標，如下 Git 倉庫的 demo [12] 為使用 Tag API 替 SAE 應用、ARMS 應用監控進行打標。

4.1.3.3 全球監控大盤的實現

上面提到了另外一個維度為區域，但是我們知道阿里雲可觀測體驗監控、應用監控等資料是區域化儲存的，以應用監控指標資料為例，使用者 cha 對應的指標儲存在上海 Prometheus 例項以及新加坡 Prometheus 例項中，要想在一張大盤中實現全域性資料的統一檢視，需要將上海 Prometheus 例項以及新加坡 Prometheus 例項進行聚合，詳細參考該文章《All in One：Prometheus 多例項資料統一管理最佳實踐》。

阿里雲提供了全域性聚合例項以及資料投遞-Remote Write 解決方案，本案例中由於全域性聚合例項不支援跨大洲，所以直接使用資料投遞-Remote Write 的解決方案，如下圖所示：

4.1.4 成效

4.1.4.1 基於標籤的資源監控大盤

如下為基於標籤的 ECS 例項監控詳情大盤，該大盤重點從資源的角度出發，關注 ECS 例項的 CPU、MEM、Disk、GPU、流量等資源使用使用情況。支援按照 cha 公司從區域視角、部門視角、專案視角、環境視角進行 ECS 資源的盤點與監控。

如下為基於標籤的全域性基礎資源監控大盤，全域性資源不僅包含 ECS，還包含使用者在阿里雲使用到的各個資源，如 SAE 應用、RDS- MySQL、Redis、RocketMQ、CLB、EIP、ES 等。

4.1.4.2 基於標籤的全域性穩定性大盤

上面提到了全域性的穩定性大盤採用自上而下的設計，考慮該大盤群裡主要為運維以及部分高階別負責人，最上層使用者引入了 SLO 的理念，設計並實現了各個部分全域性 SLO，關於 SLO 這塊的最佳實踐我們後續會在公眾號以及阿里雲可觀測的官方文件中進行推出。

下層按照剛才的設計進行分組的展示各部分需要關注的穩定性指標，比如上圖中針對端側新增訪問趨勢、異常趨勢、最大內容渲染耗時、首次輸入延遲耗時、累計佈局配置偏移等；應用監控這塊除了關注常見的黃金三指標外，可以按需增加常見的一些如異常監控、JVM 監控、慢 SQL、慢呼叫等檢視；其他中介軟體/容器/ECS 的配置不一一展開。

4.2 標籤體系加持下的告警生命週期管理

4.2.1 客戶背景

某著名垂直電商 A 公司目前已經進入深度用雲的階段，公司目前面臨如下的問題：

使用者資源/應用歸屬不同的供應商，作為統一運維團隊需要將各自資源的告警指向對應的供應商，如果針對單個告警逐一配置，效率低下&繁瑣；

作為 CTO、架構師團隊等需要針對公司層面的告警治理進行統一的度量，同時能從供應商的視角去審查&量化應急響應能力，衡量供應商的水平與能力。

4.2.2 解決方案

4.2.2.1 基於標籤的通知分發策略

當前的解決方案是基於標籤對供應商的相對應的業務應用和雲資源進行打標，利用標籤進行告警的分發；同時在告警的事件中儘可能覆蓋全面的上下文資訊，方便告警接收人獲取更多的資訊提高告警的定位效率。

圖中為解決方案的示意圖，其中階段 1 &階段 2 中的綠色部分表示阿里雲當前已經支援的能力，灰色部分為正在支援中。

4.2.2.1 基於標籤的應急 SLO 度量

應急 SLO 度量旨在量化應急響應能力，應急響應能力包含事件接手率、故障恢復時長 MTTR、恢復時間等。使用者可以根據自身業務和組織架構，透過自定義標籤組織自定義 SLO 大盤，基於指標、大盤進行資料分析，從而牽引穩定性考核。

廣告時間

1）阿里雲可觀測監控 Prometheus 版 VS 開源 Prometheus

阿里雲可觀測監控 Prometheus 版全面對接開源 Prometheus 生態，支援型別豐富的元件監控，覆蓋絕大部分開源基礎設施軟體指標採集能力。提供多種開箱即用的預置監控大盤，並整合豐富的 Kubernetes 基礎監控以及常用服務預設看板，且提供全面託管的 Prometheus 服務。阿里雲可觀測監控 Prometheus 版的優勢可以歸納為“開箱即用”、“低成本”、“開源相容”、“資料規模無上限”、“高效能”、“高可用性”。

2）產品計費

目前，可觀測監控 Prometheus 提供每月 50GB 免費額度，全面降低使用者可觀測成本。點選此處，立即開通！

相關連結：

[1] 阿里雲標籤

https://account.aliyun.com/login/login.htm?oauth_callback=htt...

[2] 資源編排 ROS

https://help.aliyun.com/zh/ros/product-overview/what-is-ros?s...

[3] ARMS 應用監控為例

https://help.aliyun.com/zh/arms/application-monitoring/securi...

[4] 文件

https://help.aliyun.com/zh/arms/application-monitoring/develo...

[5] ARMS 控制檯

https://account.aliyun.com/login/login.htm?oauth_callback=htt...

[6] SLS 告警

https://help.aliyun.com/zh/sls/user-guide/labels-and-annotations

[7] 文件

https://help.aliyun.com/zh/arms/alarm-operation-center/use-al...

[8] Prometheus 告警規則

https://help.aliyun.com/zh/arms/prometheus-monitoring/create-...

[9] 透過 Kubernetes Label 分發告警

https://help.aliyun.com/zh/arms/alarm-operation-center/use-k8...

[10] 告警運維中心

https://account.aliyun.com/login/login.htm?oauth_callback=/#/...

[11] TagResources

https://help.aliyun.com/zh/resource-management/tag/developer-...

[12] demo

https://github.com/OuyangKevin/CloudAssistantTool/tree/main

參考文件：

[1] 阿里雲標籤概述

https://help.aliyun.com/zh/resource-management/user-guide/tag...

[2] 阿里雲 ARMS 應用監控自定義 RAM 授權策略