4. 服务画像数据采集：从CMDB、APM、日志、监控系统自动获取画像数据
服务画像的构建依赖于多源数据的自动采集与融合。单一数据源（如仅依赖CMDB）无法完整描述服务的运行时特征与依赖关系。本章定义标准化的数据采集接口与适配器，覆盖配置管理数据库（CMDB）、应用性能管理（APM）、日志平台、基础设施与业务监控四大数据源，确保画像数据具备实时性、准确性和完整性。
4.1 数据源分类与采集策略
根据数据更新频率与获取方式，将画像数据源分为静态基线、动态指标、事件流三类：
| 数据源类型 | 典型系统 | 数据内容 | 采集频率 | 采集方式 |
|---|---|---|---|---|
| 静态基线 | CMDB、服务目录 | 服务名称、Owner、技术栈、部署拓扑 | 每日/事件驱动 | API 拉取 + Webhook 变更推送 |
| 动态指标 | APM、Prometheus、Zabbix | 请求量、延迟、错误率、CPU/内存水位 | 分钟级（1-5min） | 时序数据库查询 + 指标聚合 |
| 事件流 | 日志平台、告警系统 | 错误日志、慢查询、告警事件、变更记录 | 准实时（秒级） | 消息队列订阅 + 日志流解析 |
最佳实践：静态基线数据作为画像的骨架，动态指标填充运行时状态，事件流提供异常上下文。三者缺一不可，否则画像将出现“有服务无状态”或“有指标无归属”的断层。
4.2 CMDB 数据采集适配器
CMDB 是服务画像的元数据基石。适配器需要处理字段映射、关系解析与增量同步。以下为标准化采集接口定义：
# 服务画像 CMDB 采集适配器接口（Python 伪代码）
class CmdbAdapter:
def fetch_service_meta(self, service_id: str) -> dict:
"""获取服务基础元数据"""
return {
"service_name": "order-service",
"owner_team": "交易平台",
"tech_stack": ["Java 17", "Spring Boot 3", "MySQL 8.0"],
"deploy_type": "Kubernetes Deployment",
"namespace": "production",
"instances": 12,
"last_deploy_time": "2025-03-10T14:30:00Z"
}
def fetch_dependency_graph(self, service_id: str) -> list:
"""获取服务依赖关系（上游/下游）"""
return [
{"type": "upstream", "target": "user-service", "protocol": "gRPC"},
{"type": "downstream", "target": "payment-service", "protocol": "HTTP"},
{"type": "datastore", "target": "order-db-master", "engine": "MySQL"}
]
def sync_changes(self, since_timestamp: str) -> list:
"""增量变更同步，减少全量拉取压力"""
return [{"service_id": "inv-001", "field": "instances", "old": 8, "new": 10}]
关键字段映射：CMDB 中的“业务线”“应用分组”需映射为画像的
domain 和 sub_domain；部署方式（VM/容器/Serverless）直接影响后续的告警阈值模板选择。
4.3 APM 与监控系统指标采集
APM 数据用于构建服务的黄金信号画像（延迟、流量、错误、饱和度）。采集时需注意指标粒度的对齐：
- 请求量（RPS）：按服务端点（Endpoint）聚合，区分正常与错误请求。
- 延迟（Latency）：采集 P50、P95、P99 分位数，用于定义“慢服务”基线。
- 错误率（Error Rate）：HTTP 5xx + 业务异常码，按滑动窗口（5min）计算。
- 饱和度（Saturation）：CPU 使用率、内存使用率、连接池占用率。
以下为 Prometheus 查询示例，用于采集服务画像所需的黄金信号：
# 采集 order-service 的 P99 延迟（过去5分钟）
histogram_quantile(0.99,
sum(rate(http_request_duration_seconds_bucket{service="order-service"}[5m])) by (le)
)
# 采集错误率（HTTP 5xx 占比）
sum(rate(http_requests_total{service="order-service", status=~"5.."}[5m]))
/
sum(rate(http_requests_total{service="order-service"}[5m]))
4.4 日志平台异常事件采集
日志数据为画像提供故障上下文与变更痕迹。采集重点包括：
| 日志类型 | 采集目标 | 画像字段映射 | 示例 |
|---|---|---|---|
| 错误日志 | ERROR / FATAL 级别 | recent_errors 列表 |
java.lang.NullPointerException |
| 慢查询日志 | 执行时间 > 1s 的 SQL | slow_queries_count |
SELECT * FROM orders WHERE ... |
| 变更日志 | 配置/发布/扩缩容事件 | change_history |
2025-03-10 14:30 发布 v2.3.1 |
| 访问日志 | 客户端 IP、User-Agent | client_profile |
移动端占比 68% |
注意：日志采集必须做字段结构化（如 JSON 格式），避免全文本正则匹配导致采集性能瓶颈。建议使用 Logstash 或 Fluentd 的 filter 插件预先解析。
4.5 多源数据融合与画像更新流程
数据采集完成后，需要经过清洗、对齐、融合三个阶段才能写入服务画像存储。整体流程如下图所示：
4.6 采集质量保障与异常处理
数据采集过程中常见问题及应对策略：
- 字段缺失：CMDB 中部分服务缺少 Owner 或技术栈信息。策略：设置默认值（如 Owner=“unknown”），并在画像中标记
data_quality: "partial"。 - 指标延迟：APM 数据上报延迟导致画像时间窗口错位。策略：采集时使用
time_offset参数对齐，允许最大 2 分钟延迟。 - 日志风暴：异常期间日志量暴增导致采集管道阻塞。策略：实施日志采样（如 10% 采样率）或限流降级，优先保证指标数据完整性。
- 数据冲突：CMDB 与 APM 中的服务实例数不一致。策略：以 APM 实时数据为准，CMDB 数据作为基线参考，差异记录到
drift_log。
采集健康检查：建议为每个数据源适配器暴露
/health 端点，返回最近一次成功采集时间戳、采集记录数、错误计数。画像系统定期（每 5 分钟）探测所有适配器健康状态，异常时触发告警。
4.7 画像数据输出格式
经过采集与融合后，服务画像以标准化 JSON 结构输出，供下游 DORA 指标计算与告警降噪使用：
{
"service_id": "order-service",
"meta": {
"owner": "交易平台",
"tech_stack": ["Java 17", "Spring Boot 3"],
"deploy_type": "Kubernetes",
"instances": 12
},
"golden_signals": {
"rps": 1520.3,
"p99_latency_ms": 245,
"error_rate_pct": 0.32,
"cpu_usage_pct": 68.5
},
"events": {
"recent_errors": ["NPE in OrderController.checkout()"],
"last_deploy": "2025-03-10T14:30:00Z",
"change_count_24h": 3
},
"dependencies": {
"upstream": ["user-service"],
"downstream": ["payment-service", "inventory-service"],
"datastores": ["order-db-master"]
},
"data_quality": "complete",
"collected_at": "2025-03-11T08:00:00Z"
}
该 JSON 结构将作为第 5 章“DORA 指标计算”与第 6 章“告警降噪策略”的输入数据源。