2. 基线核验概念：什么是基线、基线核验的目标、基线在混沌实验中的重要性

2.1 什么是基线（Baseline）

在混沌工程与可观测性体系中，基线是指系统在正常、无故障状态下，关键性能指标（KPI）与行为模式的集合。它代表了系统在稳态运行时的“健康快照”，是后续所有混沌实验的参照坐标系。

基线不是单一数值，而是一个多维度的度量集合，通常涵盖以下层面：

维度 典型指标 说明
延迟 P50 / P95 / P99 响应时间 请求从发出到收到完整响应的时间分布
吞吐量 RPS（每秒请求数）、TPS（每秒事务数） 系统在单位时间内能处理的请求量
错误率 HTTP 5xx 比例、业务错误码比例 失败请求占总请求的百分比
资源利用率 CPU / 内存 / 磁盘 IO / 网络带宽 基础设施层面的饱和度
链路拓扑 服务调用关系、Span 数量、Trace 深度 Jaeger 等工具采集的分布式调用链结构
实践要点：基线数据应采集至少 7 天以上的连续运行数据，覆盖业务高峰与低谷时段，排除因发布、扩缩容等变更引起的异常波动。Jaeger 的 jaeger-query 服务提供的 /api/traces 接口可用于批量导出历史 Trace 数据，辅助构建基线。

2.2 基线核验的目标

基线核验（Baseline Verification）是在混沌实验执行前和执行后，将系统当前状态与预先定义的基线进行对比，以判断系统是否处于“正常”范围的过程。其核心目标包括：

  • 确认实验前提有效：在注入故障前，确保系统确实处于基线状态，避免因系统本身已存在故障而导致实验结论失真。
  • 量化故障影响范围：通过实验后指标与基线的偏差，精确衡量故障对延迟、吞吐量、错误率等关键维度的影响程度。
  • 验证恢复能力：在故障注入结束并执行恢复操作后，再次核验系统是否回归基线，以此判断自愈或手动恢复措施的有效性。
  • 建立可重复的评估标准：使不同时间、不同场景的混沌实验具有统一的比较基准，避免主观判断。
基线核验公式：
故障影响度 = (实验后指标值 - 基线指标值) / 基线指标值 × 100%
当影响度超过预设阈值（如延迟增加超过 20%）时，判定为故障影响显著，需要进一步分析根因。

2.3 基线在混沌实验中的重要性

基线是混沌实验的“锚点”，没有基线，实验将失去判断标准。其重要性体现在以下三个关键阶段：

基线在混沌实验中的核心作用 阶段一：实验前 确认系统处于稳态 排除已有故障干扰 设定实验预期偏差阈值 阶段二：实验中 实时对比当前指标与基线 触发告警（偏差超阈值） 记录故障注入的即时影响 阶段三：实验后 验证系统是否回归基线 评估恢复策略有效性 输出实验报告与改进项 Jaeger 在基线核验中的关键作用 • 通过 Trace 数据构建“链路级基线”：正常状态下各服务的 Span 耗时分布、调用深度、错误 Span 比例。 • 实验期间实时对比：Jaeger 的 /api/metrics 端点可输出 Span 延迟直方图，与基线直方图进行 KS 检验。 • 实验后根因定位：当指标偏离基线时，通过 Jaeger UI 的 Trace 搜索功能，快速定位到具体故障链路。 • 自动化核验：结合 Jaeger gRPC 接口与 Prometheus 告警，实现基线偏差的自动检测与告警。

2.4 基线核验的常见误区

⚠️ 常见误区一：基线是静态的
基线应随系统版本迭代、流量模型变化而定期更新。使用三个月前的基线数据核验当前实验，可能导致误判。建议每次混沌实验前，重新采集最近 24 小时的稳态数据作为“动态基线”。
⚠️ 常见误区二：只关注单一指标
仅看 P99 延迟可能掩盖吞吐量下降的问题。例如：故障导致部分请求超时重试，P99 可能不变，但 RPS 下降 50%。基线核验应覆盖延迟、吞吐量、错误率、资源利用率四个维度，缺一不可。
⚠️ 常见误区三：忽略链路拓扑变化
故障可能导致服务调用链发生变化（如熔断后跳过下游服务）。这种拓扑变化在 Jaeger 中表现为 Trace 的 Span 数量减少或服务节点缺失。基线核验应包含“链路拓扑结构”的对比，而不仅仅是数值指标。

2.5 基线核验的实践流程

在混沌工程中，基线核验通常遵循以下步骤：

  1. 基线采集：使用 Jaeger + Prometheus + Grafana 组合，连续采集 24 小时以上的系统指标与 Trace 数据，计算各指标的均值、P50、P95、P99 以及标准差。
  2. 基线存储：将基线数据存入时序数据库（如 Prometheus TSDB）或对象存储（如 S3），并标记版本号与采集时间窗口。
  3. 实验前核验：在注入故障前 5 分钟，采集当前系统快照，与基线进行对比。若偏差超过 5%，则中止实验，排查系统异常。
  4. 实验中监控：持续采集指标，与基线实时对比，当偏差超过预设阈值（如延迟增加 30%）时，自动触发告警并记录故障注入时间点。
  5. 实验后核验：恢复操作完成后，等待 5 分钟（或系统稳定后），再次采集快照与基线对比。若指标回归到基线 ±10% 范围内，则判定恢复成功。
  6. 基线更新：将本次实验后的稳态数据纳入基线库，用于下一次实验。
Jaeger 基线核验代码示例（Python + Jaeger gRPC）： 
from jaeger_client import Config
from datetime import datetime, timedelta

# 1. 采集基线 Trace 数据
def collect_baseline_traces(service_name, hours=24):
    config = Config(
        config={'sampler': {'type': 'const', 'param': 1}},
        service_name='baseline-collector'
    )
    tracer = config.initialize_tracer()
    # 通过 Jaeger gRPC 查询接口获取历史 Trace
    # 此处省略具体 gRPC 调用细节
    traces = query_jaeger_traces(
        service=service_name,
        start_time=datetime.utcnow() - timedelta(hours=hours),
        end_time=datetime.utcnow()
    )
    # 计算基线指标
    baseline = {
        'p50_latency': calculate_percentile(traces, 50),
        'p95_latency': calculate_percentile(traces, 95),
        'p99_latency': calculate_percentile(traces, 99),
        'error_rate': calculate_error_rate(traces),
        'avg_span_count': calculate_avg_span_count(traces)
    }
    return baseline

# 2. 核验当前状态是否偏离基线
def verify_baseline(current_metrics, baseline, threshold=0.2):
    deviations = {}
    for key in baseline:
        if baseline[key] == 0:
            continue
        deviation = abs(current_metrics[key] - baseline[key]) / baseline[key]
        if deviation > threshold:
            deviations[key] = deviation
    return deviations

2.6 基线核验与可观测性的关系

基线核验是可观测性体系在混沌工程中的具体应用。可观测性提供了“数据”，基线核验提供了“判断标准”。二者结合，才能从海量数据中提取出有意义的故障信息。

可观测性支柱 在基线核验中的角色 Jaeger 相关能力
指标（Metrics） 提供延迟、吞吐量、错误率的数值基线 Jaeger 内置 Prometheus 指标端点（/metrics）
链路（Traces） 提供服务调用拓扑、Span 耗时分布、错误 Span 的基线 Jaeger UI 的 Trace 对比功能、/api/traces 查询接口
日志（Logs） 提供异常日志的基线（如每分钟错误日志数量） Jaeger 与日志系统（如 ELK）的关联分析

在混沌实验中，基线核验将这三个支柱的数据统一到一个评估框架中，使故障排查从“凭经验猜测”转变为“数据驱动决策”。

← 上一章 📖 返回目录 下一章 →