可观测数据质量从“看不见”到“修得准”

一个 0-100 的分数，就能告诉你：你的可观测数据，到底行不行？

以为可观测上线就万事大吉了？

Trace 有了、指标有了、日志也接了，怎么还是查不出问题根因？真相可能是：70%的可观测问题出在数据质量！

• 孤儿 Span 像“断头链”，追踪断片

• 高基数 span.name，卡死你的指标面板

• service.name 空了，直接“认不出”是谁

• 1 小时 100 万条日志，90%没 severity_number，告警形同虚设

你以为你有数据，其实你只有“噪音”。

Instrumentation Score 规范

Instrumentation Score 是 CNCF 社区主导、供应商中立、完全开源的一个 OTel Instrumentation 质量标准，但目前还处于比较初级的阶段，GitHub 地址在这里：

https://github.com/instrumentation-score/spec

它定义了四大类评估对象：

1. 资源：你的服务是谁？service.name、service.namespace、service.version 这些基础信息必须完整。 没有 service.name，你连“这是哪个服务”都不知道，查问题直接懵。

2. 追踪：你的调用链完整吗？有没有“孤儿 Span”？span.name 是不是塞满了 session_id 导致高基数？

3. 指标：你的指标维度是不是爆炸了？单位是不是乱七八糟？http_duration_ms 和 http_duration_seconds 混用，告警直接失灵。

4. 日志：你的日志有 severity_number 吗？有 trace_id 能关联追踪吗？还是说，90%都是 INFO 级别的“Hello World”？

每一条规则都有影响等级：Critical、Important、Normal、Low，对应权重 40、30、20、10。

每个规则包括：

最终分数 = 加权通过率×100

• 90+：优秀，安心睡大觉

• 75-89：良好，小修小补

• 50-74：危险，赶紧排期

• <50：爆炸，生产事故预告片

目前包括下面这些规则：

1. Resource 规则（RES-XXX）：评估服务/资源元数据质量

这些规则确保资源属性（如 service.name）完整，用于服务识别和分组。

2. TraceSpan 规则（SPA-XXX）：评估追踪 Span 完整性和规范

这些规则针对分布式追踪，确保 Span 链路完整、无高基数。

3. Metric 规则（MET-XXX）：评估指标维度和一致性

这些规则防止指标高基数，确保聚合高效。

4. Log 规则（LOG-XXX）：评估日志结构和关联

这些规则确保日志可搜索、可关联追踪。

日志易观察易如何基于这套规则对可观测数据的质量进行评分呢？

可以利用日志易 SPL 来每个规则进行计算：

比如上面的规则 SPA-005, SPL 命令如下：

index=_o11y_trace * | eval root_span_name = business | eval trace_id = traceId | stats count() as total_spans , count(eval(kind=="Client" && parentId=="")) as violation_spans_count , values(trace_id) as example_trace_ids, values(root_span_name) as example_root_span_names, min(timestamp) as first_seen, max(timestamp) as last_seen by service | eval firstTime=formatdate(tolong(first_seen),"yyyyMMdd HH:mm:ss") | eval lastTime=formatdate(tolong(last_seen),"yyyyMMdd HH:mm:ss")  | eval violation_pct = round(violation_spans_count/total_spans*100,2) | sort by violation_spans_count | eval Rule = "SPA-005" | eval Impact = "Low (10分)" | table service, orphan_spans_count, example_trace_ids, example_root_span_names, Rule, Impact,violation_pct, firstTime, lastTime

不光对规则是否违反进行计算，还需要获取违反的示例，首次/最后一次违反的时间，以及每个服务违反的比例。

最后对每个规则进行评分汇总，官方评分公式：

变量解释：

• N：影响级别总数（如 4 个：Critical、Important、Normal、Low）

• Lᵢ：第 i 个影响级别

• Wᵢ：该级别的权重（Critical 权重最高）

• Pᵢ：该级别通过的规则数

• Tᵢ：该级别总规则数

不过这个评分规则是个“二元（Pass/Fail)”的评估规则，没有考虑影响范围，他没有考虑到是 1 个服务违反了，还是 100 个服务违反了，而只关心这个规则有没有违反。所以在上面的计算中会计算每个服务违反的比例，增加“违规程度”字段，用于：

1. 服务级分数

2. 加权扣分（可选）

3. 告警优先级

来进行增强评分。另外，还可以提供规则和服务级别的下钻，查看每个规则/服务的数据质量得分情况。

请记住：可观测性不是“堆数据”，而是“用好数据”。