作者：阳其凯（逸陵）

在当今数字化转型加速的时代，企业 IT 系统的复杂度与日俱增，如何高效地管理和监控这些系统成为了一项挑战。阿里云作为全球领先的云计算服务商，提供了一整套全面的可观测性解决方案，覆盖从业务、端侧（小程序、APP、H5 等）、应用、中间件、容器/ECS 等全栈的监控体系，旨在帮助企业构建强大而灵活的可观测性体系。其中，标签（Tag）作为一种核心组织和管理手段，在阿里云可观测体系中扮演着至关重要的角色。本文将深入探讨阿里云可观测系列产品中标签的应用，以及如何运用标签在阿里云可观测产品体系下进行体系化建设并给出相关最佳实践。

01 标签的基础与价值

1.1 什么是标签

标签是一种元数据（Meta），用于附加到云资源上，是一些充当元数据的词和短语，以实现资源的分类、管理和过滤。标签（Key:Value）由标签键和标签值进行组成：

标签键（Key）：标签管理中用于定义一个分类的值，多由用户定义来代表不同的业务分类。
标签值（Value）：标签键下一系列描述性属性，多用来陈述一个标签键代表的类型下都有哪些选项。

那么这里有一个问题需要重点关注，那就是阿里云的标签为啥是键值对的形式？业界也有部分的产品/系统采用的是单值的形式，带着疑问我们继续往下。

1.2 阿里云标签分类

阿里云标签^[^1]分为如下几个类别：自定义标签、系统标签、创建者标签、预置标签。

自定义标签：是由用户自己创建的，由用户进行定义以及维护，灵活性非常高；创建自定义标签，必须同时绑定资源。单次最多可以创建 10 个标签，并且标签键不可重复。如果需要仅创建标签，并规划标签键和值，需要使用预置标签。自定义标签也是本篇文章核心关注的内容。
系统标签：系统标签是由系统自动产生，通常以一种相对标准化的形式呈现数据关系的一种标签。在一些固化场景下，用户可以借助系统标签来辅助业务使用。系统标签可以对用户可见，但是不支持用户创建或删除。只有云产品可以创建系统 TAG，系统 Tag 必须以 acs: 开头。如下所示为：

创建者标签：用户在创建资源时，系统会默认为资源打上一个创建者标签（createdby 标签）。创建者标签是系统标签，对用户可见。创建者标签可以帮助用户分析费用和账单，实现企业云上成本管理,还可以帮助用户进行创建者信息溯源，提升资源管理便利性。
预置标签：预置标签是指预先创建并作用于所有地域的一种标签，非常适合在标签规划阶段使用。用户可以在标签规划阶段创建预置标签，然后在标签实施阶段绑定具体的云资源。

1.3 阿里云标签的通用价值

阿里云全球基础设施都需要支持标签，标签是阿里云整体资源分组能力，而不是单个产品的分组能力，标签体系能力全面提升了阿里云生态能力，通过标签，用户可以基于业务场景、环境、成本中心等维度对资源进行逻辑分组，进而实现精细化管理和监控。

从管理层面，可以基于标签做分组访问控制；分组审计；分组安全管理；方便从全局搜索。
从运维层面，可以基于标签做客户侧主动运维，分组监控报警诊断，分组消息，动态缩扩容。
从财务层面，可以基于标签做多维度分账管理、自定义账单视图、多维度成本分析。
从部署层面，可以基于标签来做资源编排。
从设计层面，可以基于标签规划成本、规划资源整体能力，以及阿里云全局产品概览视角。

1.4 阿里云可观测体系下的标签价值

在阿里云可观测体系下，合理利用标签能够带来以下几大价值：

资源组织与发现：标签使资源易于搜索和分类，帮助运维人员快速定位和管理相关资源。
成本分析与优化：结合阿里云的成本管理服务，标签可辅助进行资源消耗的细粒度分析，支持成本控制和优化。
自动化与策略实施：标签是自动化规则和策略执行的关键依据，比如基于标签的报警策略或自动扩展规则。
合规性与安全管理：通过标签标识资源的敏感性和合规要求，支持安全策略的实施和审计。

02 阿里云可观测体系标签的应用

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 会默认写入如下实例标签：

标签Key	说明
workloadKind	应用实例所在的工作负载的类型，例如Deployment。
workloadName	应用实例所在的工作负载的名字。
clusterName	应用实例所在的K8s集群名。
namespace	应用实例所在的K8s命名空间。
version	镜像的tag。可被自定义实例标签覆盖。
agentVersion	探针版本。

除了默认实例标签外，您还可以添加自定义实例标签。同时，实例标签还会完整地继承应用标签，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 在收集指标过程中，会把实例相关的其他元数据信息以标签形式附加至相应指标上。

标签名	说明
id	实例ID。
instanceName	实例名称。
resourceGroupId	资源组ID。
resourceGroupName	资源组名。
regionId	实例区域。
zoneId	可用区。
userId	主账号ID。
namespace	接入环境ID。
product	所属云产品。
measure	云监控对应的指标名。
measure_desc	云监控对应的指标描述。

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-started/cloud-service-observable

3）进入共享版的 Grafana 进行数据的 explore，Expore 页面中选择云服务对应的数据源，比如查询 AliyunEcs_load_1m 指标。

域名	地址
中国	https://g.console.aliyun.com
美国	https://gnext-us.console.aliyun.com
欧洲	https://gnext-eu.console.aliyun.com
日本	https://gnext-jp.console.aliyun.com
东南亚	https://gnext-ap.console.aliyun.com

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。

03 可观测标签推荐最佳设计

为了最大化可观测标签的价值，建议遵循以下标签设计原则。

3.1 命名标准化原则

标签始终使用标准化、区分大小写的格式，为了兼容各个云产品大小写支持差异，建议全部使用小写。
可观测中相关指标数据存储在 Prometheus 中，所以标签的 Key 建议满足 Prometheus 命名规范，即符合正则规则：^[a-zA-Z_][a-zA-Z0-9_]*$。
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 标签。

04 阿里云可观测体系下标签实践案例

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 等）。

按照上面标签的设计原则，客户定义了如下的标签，下面仅给出设计参考。

标签key	说明	标签value
cha_env	标识研发环境	uattestprod
cha_business	标识业务线	B端C端
cha_project	标识项目	订货助手账单服务交易中台采购系统门店营销中台支付中台会员中台商品中台

这里针对云服务的标签需要明确一下：如果云服务采用上面形式的标签，默认指标中不会带上自定义标签，需要在接入的时候手工将自定义的标签加入白名单，否则采用 o11y.aliyun.dev/ 前缀的标签，这里建议采用通用的非前缀标签形式，方便标签的统一。

4.1.3.2 建立标签关系

标签关系的建立目前主要分为手工页面配置方式以及 API 方式。

手工页面方式：进入到各个云产品控制台以及可观测控制台中体验监控、应用监控等模块，手工将对应的标打上即可；
API 方式：可以使用阿里云标签服务的接口 TagResources^[^11]完成打标，如下 Git 仓库的 demo^[1^2]为使用 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 版的优势可以归纳为“开箱即用”、“低成本”、“开源兼容”、“数据规模无上限”、“高性能”、“高可用性”。