监控观测数据标签体系的应用实践

前言

在复杂的应用系统环境下，监控数据量呈现出海量且繁杂的特点，如何高效地对这些监控数据进行管理、分析以及从中挖掘出有价值的信息，成为保障系统稳定运行和优化性能的关键所在。数据标签体系的建立就变得十分重要，它能够为监控数据赋予清晰的 “身份标识”，如同给数据穿上了带有详细说明的 “外衣”，让用户可以更便捷、精准地理解和运用这些数据，进而提升应用系统监控工作的整体效能。接下来，将探讨关于监控数据标签体系相关的内容。

标签的意义

标签是标识一个数据点采集对象的属性集合，是对监控数据的一种具有特定含义的标识，从不同维度对数据进行描述，将原本看似无序的监控数据进行有序分类和细化。数据标签化是做分类监控分析，数据间关联分析的基础。在监控数据分类分析中，利用数据标签可依其属性精准划分海量数据，基于分类分析关键信息、了解分布及变化趋势。数据间的关联分析依赖数据标签化，借助相同标签使不同数据产生关联，唯有如此用户才能高效挖掘数据价值，让其在应用系统监控及相关决策等方面发挥强大作用。

观测云的核心能力之一是把采集到的不同类型的监测数据，包括 metrics、rum、trace 和 logs 等，存放在统一平台上。同时，还提供了极为灵活和强大的数据标签化功能，把平台上各类监控数据实现分类和关联性。这种标签化能力带来的好处和效果包括：

提升数据可理解性

监控数据往往涉及众多技术指标和复杂的业务信息，单纯的数据值很难让人迅速把握其含义和背后反映的系统状态。而标签可以直观地表明数据所对应的业务环节、系统资源类型或者数据性质等关键信息，使得不同角色的人员（运维人员、开发人员、业务人员等）都能轻松理解数据内容。

便于精准分析与查询

在海量的监控数据中，若要查找特定业务流程或者特定系统性能方面的数据，如果没有标签，就如同大海捞针。有了标签，用户可以通过标签条件进行快速筛选和精准定位，极大地提高数据分析的效率和准确性。

助力故障排查与性能优化

当系统出现故障或者性能问题时，借助标签能够迅速聚焦到相关的数据范围。以订单处理为例，从前端发起请求到后端数据处理以及与外部接口交互等整个链路中各环节的数据关联情况，从中发现到底是哪个子步骤耗时过长、第三方接口故障还是数据库操作异常等导致了订单处理出现问题，从而精准定位故障根源等。以此制定优化策略，助力故障解决及性能提升，实现相应目标。

标签的设计和配置

1. 设计思路

在着手进行监控数据的标签设计时，首要任务便是明确数据标签化的需求与目标。例如：核心需求聚焦在两个关键方面：其一，借助数据标签化实现对数据的分类统计，让繁杂的数据能够依据相应标签有序归类；其二，利用标签化在不同的数据对象之间构建起关联关系，使数据间的内在联系得以清晰呈现。

如上图所示，从纵向维度来看，依据业务系统组织架构来确定分类维度是一种行之有效的方法。具体而言，采用从大类范围逐步细化至小类范围的分层划分方式，如此一来，后续在面对海量监控数据时，便能依据不同的范围层次，迅速地开展分类分析工作，并且在筛选查询特定数据时也能更加高效便捷。而从横向维度考量，针对不同数据对象之间存在的关联需求，需要为它们打上相同的标签，以此建立起数据关联。例如，若期望链路调用数据和日志数据之间能够实现关联分析，那就应当在这两种不同的数据对象上统一打上对应的 trace_id 标签。

秉持这样的思路，在整个标签设计的过程中，紧密结合实际的系统环境，并充分考量关联分析的具体需求，从中不断提炼、抽象出具有共性的标签，进而构建起一套完善的数据标签体系，为后续的数据分析、故障排查以及系统性能优化等工作筑牢坚实基础。

2. 常见配置方式

2.1 全局标签配置

DataKit 是一款功能强大的数据采集 agent。在 DataKit 上设置全局标签后，所有通过 DataKit 进行采集和上报的数据默认都将自动设置上数据标签。如果被采集上来的数据中，本来就带有同名的 Tag，那么 DataKit 不会再追加这里配置的全局 Tag。

这里分两类全局标签，说明如下。

2.1.1 主机类全局标签

通过 DataKit 采集上报的数据都会打上该选项下配置的标签信息。该配置选项在 &DATAKIT_HOME/conf.d/datakit.conf 文件中通过 [global_host_tags] 配置项实现。

2.1.2 选举类全局标签

对于集群多节点环境，为了避免不同节点上的 DataKit 对一些公共指标重复采集，需要用到 DataKit 的选举机制。对于该场景下，需要设置选举类全局标签。该配置选项在 &DATAKIT_HOME/conf.d/datakit.conf 文件中的如下配置项实现。

[election][election.tags]

2.2 采集器标签配置

DataKit 中每个不同数据对象的采集都有自己对应的采集配置文件，位于 &DATAKIT_HOME/conf.d 的下层子目录中。不同的数据对象可以通过对应采集配置文件中的如下配置项打上特定的数据标签。

[inputs.xxx.tags]# some_tag = "some_value"# more_tag = "some_other_value"

2.3 RUM自定义标签配置

如果需要对 RUM 相关的监控数据配置自定义标签，RUM SDK 提供如下的方法进行自定义的标签设置。

DATAFLUX_RUM.setGlobalContextProperty('<CONTEXT_KEY>', '<CONTEXT_VALUE>');

关于 RUM 的自定义标签的详细说明，请参考如下链接：
自定义添加额外的数据 TAG - 观测云文档

2.4 链路自定义标签配置

除了在数据采集器 DataKit 上给链路数据打标签外，同时也可以在链路数据的生成端上设置对应的自定义标签。以使用 ddtrace 为例，在应用启动前，设置如下的环境变量来设置自定义标签。

DD_TAGS="key1:value1,key2:value2"

2.5 Pipeline动态标签配置

Pipeline 支持对多种数据类型进行处理。通过编写 Pipeline 脚本，可以自定义切割出符合要求的结构化数据，并把切割出来的字段使用 set_tag() 方法作为自定义标签使用，从而用户可以快速地进行筛选统计、关联分析，帮助用户快速去定位和解决问题。

关于 Pipeline 的详细介绍，请参考如下链接中的内容：
Pipelines - 观测云文档

应用场景案例

下面对使用数据标签实现全链路和数据关联进行高效分析进行说明：

在服务调用监控与分析的过程中，需要实现全链路的打通。当问题出现时，能够清晰知道问题是发生在哪个环节。同时，需要借助在不同数据类型上设置适合的标签，在分析问题时，能让该链路点相关的其他监控数据关联起来，进而开展关联分析工作。

1. 标签配置设计

如上图所示，在该案例中考虑三个方面的标签配置：

全链路串联：使用 trace_id 标签。这个标签用于在全链路中串联不同数据源的数据，可以追踪从用户前端应用访问（RUM）到后端服务链路调用（APM）的全链路数据。同时，可以通过 trace_id 快速关联服务调用链路和对应产生的日志做关联分析，便于排查系统性能问题和故障。
服务关联：使用 service 标签。这个标签用于关联不同服务的数据。例如：链路中 mysql 调用的服务名标签 service 为“mysql”。同时，对采集 MySQL 的运行指标设置服务名标签 service 也为“mysql”。那么，在查看 mysql 调用链路的时候，就可以快速关联查看 MySQL 数据库在链路执行时间点上的运行状态。
主机关联：使用 host 标签。这个标签用于将同一主机上的数据进行关联，便于分析主机相关的性能和问题。

2. 效果

通过上述标签配置，用户不仅能够借助 trace_id 查看完整的链路调用情况，还可以依据链路上的 service 或 host 标签，关联到具有相同 host 标签值的主机运行指标，或者具有相同 service 标签值的 MySQL 指标等相关数据。这种标签设置有助于提升监控数据的管理和分析效率，帮助运维人员和开发人员更好地理解和优化系统。