4. Metric分类体系：基础设施层、应用层、业务层Metric的划分与关联

在构建服务画像健康度模型时，Metric 的分类是第一步，也是最关键的一步。错误的分类会导致告警阈值设计混乱、指标关联断裂，最终使健康度评分失真。本章将 Metric 划分为三个层次：基础设施层、应用层和业务层，并阐述各层的核心指标、划分原则以及跨层关联方法。

4.1 三层Metric划分原则

划分的核心依据是“观测距离”与“业务语义”：

• 基础设施层：关注资源供给能力，距离业务最远，语义通用（CPU、内存、网络）。
• 应用层：关注服务运行状态，距离业务中等，语义与中间件/框架相关（请求延迟、错误率、线程池）。
• 业务层：关注用户价值实现，距离业务最近，语义与具体业务逻辑绑定（订单量、支付成功率、转化率）。

4.2 各层Metric详细清单与对比

4.3 三层Metric关联模型

关联的核心是“故障传导链”：基础设施异常 → 应用性能劣化 → 业务指标下跌。健康度模型必须能够通过跨层指标关联，快速定位故障根因。

4.4 跨层关联的三种模式

在实际落地中，跨层关联并非简单的“三层堆叠”，而是需要根据场景选择不同的关联模式：

• 模式一：标签关联 — 通过统一的标签体系（如 service_name、host、region）将三层 Metric 绑定到同一个服务实体上。这是最基础、最通用的模式。
• 模式二：时间序列关联 — 将三层 Metric 的时间序列对齐到同一时间窗口（如 1 分钟），通过相关性分析（Pearson、Spearman）自动发现异常传导关系。适用于动态基线场景。
• 模式三：调用链关联 — 在应用层和业务层之间，通过分布式追踪（Trace）将一次业务请求的完整路径串联起来，精确到每一次 RPC 调用和数据库访问。适用于根因定位。

4.5 实践：从Metric分类到健康度评分

在服务画像健康度模型中，三层 Metric 的权重分配直接影响最终评分。以下是一个经过生产验证的权重分配示例：

# 健康度评分计算伪代码
def calculate_health_score(infra_metrics, app_metrics, biz_metrics):
    # 基础设施层权重 25%
    infra_score = weighted_average(infra_metrics, weights={
        'cpu_usage': 0.3,
        'memory_usage': 0.3,
        'disk_iops': 0.2,
        'network_bandwidth': 0.2
    })
    
    # 应用层权重 35%
    app_score = weighted_average(app_metrics, weights={
        'p99_latency': 0.4,
        'error_rate': 0.3,
        'qps': 0.15,
        'gc_pause': 0.15
    })
    
    # 业务层权重 40%
    biz_score = weighted_average(biz_metrics, weights={
        'order_success_rate': 0.5,
        'payment_success_rate': 0.3,
        'user_login_count': 0.2
    })
    
    # 最终健康度 = 0.25 * infra_score + 0.35 * app_score + 0.40 * biz_score
    return 0.25 * infra_score + 0.35 * app_score + 0.40 * biz_score