可观察性

从一条观测，到一个可信的判断

日志、指标和 Trace 解释运行过程，业务记录确认已提交结果。理解数据经过了哪里、采样覆盖什么，以及空结果意味着什么，才能让图表真正帮助判断。

先区分运行诊断与业务结果

“请求为什么慢”与“费用是否已记账”需要不同的读取入口。前者可以结合 Trace、请求时长和依赖调用解释阶段；后者需要回到原请求账本。日志说明某段代码曾报告什么，不能替代持久状态中的提交结果。

Telemetry 负责共享的上下文传播、HTTP 观察与标准信号导出；OLAP 负责收集、存储和原生查询。具体项目决定业务事件、可记录字段和分析含义。接收器收到数据、导出调用完成、后端查询到数据，是这条路径上不同的观察点。

流式请求很容易出现这样的时序：响应头很快返回，正文随后持续输出，最后才正常结束、失败或被放弃。Telemetry 分别记录响应头可用的时间与完整交换时长；获得响应头后，观察责任移交给返回的正文对象，直到正文的真实终点。

因此，一条“首个响应很快”的记录不能证明完整回答很快，也不能证明所有字节已送达。计时包装只观察原服务的一次调用，不增加缓存正文、业务重试或第二次请求。若应用需要更细的阶段解释，应在相同原调用中定义有明确含义的观察。

观测链路有明确的容量和丢失语义。生产端队列满时可以丢弃观察；Collector 的队列、重试期限和内存上限也是资源选择，不是无损送达保证。业务完成不会等待每条遥测被后端保留，关闭导出器同样不构成接收端已保存的证明。

查询返回空集合，可能只是该时间窗没有匹配记录；查询失败则连这个观察都没有取得。展示保留旧读数时，需要说明原观察时间，不能因为页面重新渲染就刷新它的年龄。只有来源、范围和单位都明确的成功观察，才能表达一个有意义的零。

OLAP 的主机概览选取 CPU 非空闲比例、可用和总内存，以及文件系统使用量。CPU 比例来自空闲比例的补数；内存和文件系统字节转换为 GiB 时保留准确单位。文件系统的设备、挂载点与 used/free/reserved 状态继续作为不同序列。

把不同挂载点简单相加，可能把别名重复计入，也可能混合无关容量。原生枚举也不保证覆盖每一个挂载点。曲线的查询评估时间不是新的采样时间；看到一条连续线，不足以确认数据新鲜或主机当前健康。

标准化采集并不意味着可以记录所有输入。路径是否允许采集、查询是否需要脱敏，由业务的实际权限和内容决定。Telemetry 保留完整、已脱敏和已省略三种路径观察含义；超出观察预算时不截取一个容易误解的前缀，也不改变原业务请求。

Trace 上下文帮助关联运行过程，却不会提升远端的信任或业务权限。认证头、Cookie 和正文不作为普通 HTTP 观察内容。项目需要选择安全的业务字段及输出目的地，把调试线索与秘密、身份证明和财务权威分开。

一份可导入的 Dashboard 仍可能使用错误单位、错误总体或过宽的选择器。规范要求用可区分的独立记录核对实际查询，覆盖有意义的空值、间断与失败；已有采集链路的有效证据可以复用，不为每个面板重做整套工作。