Observability

可观测性是指通过软件系统发出的遥测数据（主要是日志、指标和追踪），充分了解系统内部正在发生什么，以便在不部署新代码的情况下回答有关系统行为的新问题。这个术语源自控制理论；Rudolf Kálmán 于 1960 年将系统定义为：如果能从系统输出确定其内部状态，该系统就是可观测的。2010 年代，随着系统拆分成许多服务、故障不再符合预先构建的仪表板，软件团队开始采用这一概念。对于机器学习系统，可观测性还涵盖数据和预测：模型接收了哪些输入、输出了什么、置信度如何，以及这些内容如何随时间变化。

日志、指标与追踪#

通常被称为可观测性支柱的三类遥测数据，分别回答不同的问题：

• 指标： 请求速率、错误率、延迟百分位数、内存和 GPU 利用率等数值时间序列。指标存储成本低，适合用于仪表板和告警。Google 的站点可靠性工程手册提出了每项服务都应衡量的四个黄金信号：延迟、流量、错误和饱和度。
• 日志： 带时间戳的单个事件记录。若以 JSON 格式记录请求 ID、模型版本和输入大小等字段，日志最便于筛选和计数。
• 追踪： 一次请求经过所触及的每项服务时的路径，以跨度树的形式记录；每个跨度都包含名称、开始时间、持续时长和属性，可以显示请求耗时所在之处。

OpenTelemetry 于 2019 年由 OpenTracing 和 OpenCensus 项目合并而成，为这三类信号提供与供应商无关的 API、SDK 和传输协议（OTLP）；Prometheus、Grafana 和 Jaeger 等后端则负责存储和显示这些数据。以下示例使用 OpenTelemetry Python SDK 追踪一次图像分类请求，为请求记录一个父跨度，并为每个阶段记录一个子跨度：

import torch
import torchvision
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import SimpleSpanProcessor
from opentelemetry.sdk.trace.export.in_memory_span_exporter import InMemorySpanExporter

# Keep finished spans in memory; a production service exports them over OTLP instead
exporter = InMemorySpanExporter()
provider = TracerProvider()
provider.add_span_processor(SimpleSpanProcessor(exporter))
tracer = provider.get_tracer("classifier")
model = torchvision.models.resnet18().eval()
frame = torch.rand(3, 1080, 1920)

# Trace one request as a parent span with a child span for each stage
with tracer.start_as_current_span("predict", attributes={"model.name": "resnet18", "image.height": 1080}):
    with tracer.start_as_current_span("preprocess"):
        batch = torchvision.transforms.functional.resize(frame, [224, 224]).unsqueeze(0)
    with tracer.start_as_current_span("inference"), torch.inference_mode():
        logits = model(batch)

spans = exporter.get_finished_spans()
names = {span.context.span_id: span.name for span in spans}
for span in spans:
    parent = names[span.parent.span_id] if span.parent else "-"
    print(f"{span.name:<11} {(span.end_time - span.start_time) / 1e6:5.1f} ms  parent: {parent}")

在 Apple M5 Pro CPU 上，程序会打印一个耗时 1.0 到 1.4 毫秒的 preprocess 跨度，以及一个耗时 7 到 9 毫秒的 inference 跨度；两者的父跨度都是 predict。此外还会打印一个耗时 8 到 10 毫秒的 predict 跨度，因此追踪结果表明请求的大部分时间都花在了模型上。跨度通过 OTLP 导出后，处理请求的每项服务都会在同一个追踪 ID 下添加跨度，Jaeger 等后端会将其绘制成一条时间线。

可观测性与监控#

模型监控通过预定义的指标、仪表板和告警阈值监视已知故障模式，例如错误率超过 1% 或推理延迟超过目标值。可观测性涵盖范围更广，能让你按客户、模型版本、摄像头或其他属性事后切分详细遥测数据，从而调查此前没有预料到的故障。Google SRE 手册要求监控回答两个问题：哪里出了问题，为什么出问题；调查会通过三类信号从第一个答案逐步找到第二个答案：

可解释 AI是一个独立领域，它会根据模型输入特征或内部激活解释模型为何生成特定输出；这些归因结果也可以作为另一类信号记录下来。

机器学习的可观测性#

机器学习系统经常会出现静默故障：计算机视觉模型可能对每个请求都返回 HTTP 200，但由于摄像头移位、光照变化或出现了新产品，其预测结果却在不断变差。因此，机器学习可观测性会在常规服务信号之外，增加有关数据和预测的遥测信息。团队会记录图像大小和亮度等输入统计数据，以检测数据漂移；追踪类别计数、空结果和平均置信度等预测分布；并在真实标签（通常几天后）到达时按细分维度计算准确率。在训练期间，回调函数会将每次运行的损失曲线、指标和系统用量发送到 TensorBoard和 MLflow等实验跟踪工具。对于 AI 智能体和大型语言模型应用，追踪会记录每条提示、检索步骤、工具调用和响应；OpenTelemetry GenAI 语义约定则统一了 gen_ai.usage.input_tokens 等属性，确保各工具的词元计数和成本可以相互对应。

Ultralytics Platform上的每个专用端点都内置了部署监控：请求数、错误率和 p95 延迟卡片；带有严重性级别以及 Errors 筛选器（用于查看错误和警告条目）的 Logs 选项卡；还有预测统计图表，分别显示热门类别、平均置信度随时间的变化、每张图像的预测数量，以及与请求延迟分开统计的模型推理时间。即使每个请求都成功，置信度曲线下滑或热门类别发生变化也会在这些图表中显现。