2. 服务画像基础:服务画像的概念、核心维度与数据采集

服务画像是将微服务、单体应用或基础设施组件在运行时产生的多维度观测数据,抽象为一张可量化、可对比、可追溯的“数字身份卡”。它并非简单的指标聚合,而是通过结构化的维度模型,将服务的性能、可靠性、成本与安全状态映射为可计算的画像标签,为后续的误差预算分配与根因定位提供标准化的参照系。

2.1 服务画像的核心概念

服务画像的本质是“运行时特征的结构化快照”。它区别于传统监控的“告警-响应”模式,强调以下三个关键特性:

  • 多模态融合:同时纳入指标(Metrics)、日志(Logs)、链路(Traces)、事件(Events)与配置(Configs),形成统一的特征向量。
  • 时间窗口化:以固定时间窗口(如5分钟、1小时)为单位计算画像快照,支持趋势对比与异常检测。
  • 可计算性:每个维度都有明确的数值或枚举值,可直接用于误差预算的消耗计算与根因相似度匹配。
关键认知:服务画像不是静态的架构文档,而是随代码发布、流量变化、资源伸缩持续演进的动态模型。误差预算台账中的每一笔“误差消耗”,都必须关联到对应时间窗口的服务画像快照。

2.2 核心维度模型:PRCS 四象限

服务画像围绕四个核心维度构建,简称 PRCS(Performance, Reliability, Cost, Security)。每个维度下包含若干可采集的原始指标与衍生标签。

维度 定义 典型指标(示例) 画像标签类型
P - 性能 服务处理请求的速度与资源效率 P99延迟、吞吐量(RPS)、CPU使用率、内存占用 连续数值、百分位分布
R - 可靠性 服务在预期时间内正常提供功能的能力 错误率、SLO达成率、故障恢复时长(MTTR)、可用性百分比 比率、布尔状态、时间序列
C - 成本 服务运行所消耗的基础设施与人力成本 每请求成本、实例数、网络出流量、存储用量 货币化数值、资源配额
S - 安全 服务暴露的攻击面与合规风险 高危漏洞数、认证失败率、敏感数据访问频次、依赖库版本 枚举、计数、合规等级
实践要点:在构建误差预算台账时,性能与可靠性维度直接决定误差消耗速率;成本维度用于评估误差修复的经济优先级;安全维度则作为“一票否决”因子——当安全画像出现严重偏移时,即使性能与可靠性达标,也应触发误差预算冻结。

2.3 画像数据采集方式

数据采集是服务画像的底层基石。根据数据源与采集频率的不同,分为以下三类主流方式:

2.3.1 埋点与代理采集(主动式)

  • 应用层埋点:通过 SDK 或字节码增强,在服务代码中插入性能计数器、错误捕获与业务标签。适用于延迟、错误率、吞吐量等核心指标。
  • Sidecar 代理:在服务网格(如 Istio)中,由 Envoy 代理自动采集流量层面的指标(请求数、响应码、TCP 连接数),无需修改业务代码。
  • Agent 采集:在主机或容器内部署采集 Agent(如 Prometheus Node Exporter、Datadog Agent),获取 CPU、内存、磁盘、网络等系统级指标。

2.3.2 日志与事件采集(被动式)

  • 结构化日志:服务输出 JSON 格式的日志,包含请求 ID、耗时、错误堆栈等字段,通过 Logstash/Fluentd 汇聚后提取画像标签。
  • 事件总线:订阅部署事件、配置变更、扩缩容事件,作为服务画像的“状态变更触发器”。

2.3.3 外部扫描与审计(周期式)

  • 安全扫描:定期对服务镜像、依赖库进行 CVE 扫描,生成安全维度画像。
  • 成本 API:对接云厂商的计费接口或内部成本分摊系统,获取按服务维度的资源消耗账单。
# 示例:通过 Prometheus 指标采集服务性能画像(伪配置)
scrape_configs:
  - job_name: 'service-perf'
    metrics_path: '/metrics'
    static_configs:
      - targets: ['svc-a:8080', 'svc-b:8080']
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_label_app]
        target_label: service_name
    # 每15秒采集一次,形成连续画像时间序列
    scrape_interval: 15s
采集避坑指南:避免“全量采集”陷阱。画像数据采集应遵循 MECE(相互独立,完全穷尽)原则,每个维度只保留对误差预算计算有直接影响的指标。例如,性能维度中“CPU 空闲率”与“CPU 使用率”信息重叠,只保留后者即可。

2.4 服务画像数据流架构

下图展示了从原始数据采集到画像标签生成的完整数据流,以及各采集方式在架构中的位置:

服务画像数据流架构 应用埋点 SDK / 字节码增强 延迟、错误率、吞吐量 Sidecar 代理 Envoy / 服务网格 流量指标、连接数 Agent / 扫描器 系统指标 / CVE 扫描 CPU、内存、漏洞数 采集管道(Prometheus / Fluentd / Event Bus) 指标聚合 · 日志结构化 · 事件过滤 画像计算引擎(时间窗口聚合 + 标签生成) PRCS 四象限 · 百分位计算 · 异常评分 画像存储(时序库 + 标签索引) 供误差预算台账查询 采集频率:15s ~ 5min 画像窗口:5min / 1h

2.5 画像标签的标准化输出

采集与计算完成后,每个服务在特定时间窗口内的画像最终输出为如下结构的标签集合:

{
  "service": "payment-svc",
  "timestamp": 1712563200,
  "window": "5m",
  "performance": {
    "p99_latency_ms": 245,
    "rps": 3200,
    "cpu_usage_pct": 68.5,
    "memory_mb": 2048
  },
  "reliability": {
    "error_rate_pct": 0.12,
    "slo_achieved": true,
    "mttr_minutes": 4.5
  },
  "cost": {
    "cost_per_request_usd": 0.00023,
    "instance_count": 12,
    "network_egress_gb": 1.8
  },
  "security": {
    "critical_vulnerabilities": 0,
    "auth_failure_rate_pct": 0.01,
    "compliance_level": "pci-dss"
  }
}
课程关联:上述画像标签中的 p99_latency_ms、error_rate_pct 等字段,将直接作为第 4 章“误差预算消耗计算”的输入因子。当某个服务的误差预算快速消耗时,SRE 可通过对比不同时间窗口的画像标签,快速锁定是性能退化还是可靠性下降导致的根因。