3. 资源模型定义
在集成资源模型的数据传输优化中，首先需要明确“集成资源模型”的定义、资源标识与元数据的设计原则，以及它与原生 Prometheus 模型的本质差异。只有理解这些基础概念，才能设计出高效、可扩展的数据传输方案。
3.1 什么是集成资源模型
集成资源模型（Integrated Resource Model, IRM）是一种将多个异构监控数据源（如 Prometheus、Zabbix、CloudWatch、自定义 Agent 等）的指标、标签、元数据统一抽象为标准化资源对象的建模方式。它不再局限于 Prometheus 原生的时间序列（Time Series）结构，而是将每个监控实体视为一个“资源”，资源包含标识、属性、状态和关联关系。
核心目标：
- 统一抽象：屏蔽不同数据源的格式差异，提供一致的资源视图。
- 高效传输：通过资源级增量更新、压缩、批量传输，减少网络开销。
- 灵活关联：支持资源之间的依赖、拓扑、层级关系，便于故障定位。
关键概念：集成资源模型中的“资源”可以是主机、容器、服务、数据库、网络设备等任何可监控的实体。每个资源拥有唯一的标识符和一组动态变化的元数据与指标。
3.2 资源标识与元数据设计原则
资源标识（Resource ID）和元数据（Metadata）是集成资源模型的核心组成部分。设计不当会导致数据冗余、传输效率低下或关联混乱。以下是必须遵循的设计原则：
| 原则 | 说明 | 示例 |
|---|---|---|
| 全局唯一性 | 资源标识必须在整个监控体系中唯一，避免跨数据源冲突。 | cluster:prod:host:10.0.1.5 |
| 不可变性 | 资源标识一旦生成，不应随资源属性变化而改变。 | 使用 UUID 或固定命名规则，而非 IP 地址（IP 可变）。 |
| 可读性 | 标识应具备一定语义，便于人工排查和自动化解析。 | svc:payment:v2 优于 uuid-abc123 |
| 元数据静态化 | 将不常变化的属性（如主机名、区域、版本）归为元数据，与动态指标分离。 | 元数据：region=us-east-1；指标：cpu_usage=75.2 |
| 标签扁平化 | 避免嵌套结构，所有元数据以键值对形式平铺，便于序列化和查询。 | {"env":"prod","team":"platform"} |
| 增量更新 | 仅传输变化的元数据字段，而非全量替换，减少传输数据量。 | 只发送 {"status":"maintenance"} 而非整个元数据对象。 |
实践建议：在资源标识中嵌入层级信息（如
cluster/service/instance），可以天然支持拓扑聚合，但需注意标识长度对传输性能的影响。建议标识总长度不超过 128 字节。
3.3 与原生 Prometheus 模型的差异
原生 Prometheus 模型以时间序列为核心，每个序列由指标名和标签键值对唯一标识。集成资源模型则从“资源”视角重新组织数据。下表列出两者的关键差异：
| 维度 | 原生 Prometheus 模型 | 集成资源模型 (IRM) |
|---|---|---|
| 数据单元 | 时间序列（Metric + Labels） | 资源对象（Resource + Attributes + Metrics） |
| 标识方式 | 指标名 + 标签组合（如 http_requests_total{method="GET"}） |
全局唯一资源 ID（如 res:svc:payment:pod-abc） |
| 元数据管理 | 标签随指标一起传输，无法区分静态与动态数据 | 元数据与指标分离，支持增量更新和版本控制 |
| 关联关系 | 无内置关联，需通过标签匹配手动关联 | 资源间可定义父子、依赖、拓扑关系 |
| 传输粒度 | 逐条时间序列推送，数据量大时冗余高 | 按资源批量推送，支持增量、压缩、去重 |
| 扩展性 | 新增维度需新增标签，可能导致基数爆炸 | 资源属性可灵活扩展，不影响标识稳定性 |
下图直观展示了两种模型在数据组织方式上的核心差异：
3.4 模型差异对传输优化的影响
理解上述差异后，可以明确集成资源模型在数据传输优化方面的几个关键优势：
- 减少重复标签传输：原生模型中，每个时间序列都携带完整标签集（如
method="GET"重复出现），而 IRM 将公共元数据提升到资源级别，仅传输一次。 - 支持增量同步：原生模型通常全量推送所有序列，IRM 可以只推送变化的资源属性或新增指标，大幅降低带宽占用。
- 拓扑感知压缩：IRM 的资源关联关系允许在传输时进行拓扑级压缩（如父节点变化时，子节点无需单独传输），原生模型无法实现。
- 降低基数爆炸风险：原生模型因标签组合爆炸导致存储和传输压力，IRM 通过资源标识与元数据分离，避免无限制的维度膨胀。
注意：集成资源模型并非完全替代 Prometheus 模型，而是在传输层之上构建的抽象层。实际落地时，通常需要在采集端将 Prometheus 指标转换为资源模型，在存储端再还原为时间序列。转换过程本身会引入一定的计算开销，需在优化方案中权衡。
下图展示了从原生模型到集成资源模型的转换流程，以及传输优化点：