Observability

Наблюдаемость — это способность понимать, что происходит внутри программной системы, по создаваемой ею телеметрии, главным образом журналам, метрикам и трассировкам, и при этом отвечать на новые вопросы о её поведении без развёртывания нового кода. Термин пришёл из теории управления: в 1960 году Рудольф Калман определил систему как наблюдаемую, если её внутреннее состояние можно определить по выходным данным. В 2010-х годах этот термин переняли команды разработчиков программного обеспечения, когда системы разделились на множество сервисов и сбои перестали соответствовать заранее подготовленным панелям мониторинга. Для систем машинного обучения наблюдаемость охватывает также данные и предсказания: какие входные данные получает модель, что она выдаёт, насколько уверена в результате и как всё это меняется со временем.

Журналы, метрики и трассировки#

Три типа телеметрии, которые часто называют основами наблюдаемости, помогают ответить на разные вопросы:

• Метрики: Числовые временные ряды, например частота запросов, частота ошибок, перцентили задержки, использование памяти и GPU; их недорого хранить, и они подходят для панелей мониторинга и оповещений. В руководстве Google по обеспечению надёжности сайтов названы четыре ключевых показателя для каждого сервиса: задержка, трафик, ошибки и насыщение ресурсов.
• Журналы: Записи отдельных событий с временными метками; они наиболее полезны в структурированном формате JSON с такими полями, как идентификатор запроса, версия модели и размер входных данных, — тогда их можно фильтровать и подсчитывать.
• Трассировки: Путь одного запроса через все затронутые им сервисы, записанный в виде дерева интервалов. Каждый интервал содержит название, время начала, длительность и атрибуты, показывая, на что ушло время запроса.

OpenTelemetry, созданная в 2019 году путём объединения проектов OpenTracing и OpenCensus, предоставляет независимые от поставщиков API, SDK и сетевой протокол (OTLP) для всех трёх типов сигналов, а такие системы хранения и отображения, как Prometheus, Grafana и Jaeger, собирают и показывают их. Этот пример трассирует один запрос классификации изображения с помощью SDK OpenTelemetry для Python, записывая родительский интервал для запроса и дочерний интервал для каждого этапа:

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}")

На CPU Apple M5 Pro выводятся интервал preprocess длительностью от 1.0 до 1.4 мс и интервал inference длительностью от 7 до 9 мс; у обоих родитель — predict. Также выводится интервал predict длительностью от 8 до 10 мс, поэтому трассировка показывает, что большая часть времени запроса уходит на модель. Когда интервалы экспортируются через OTLP, каждый сервис, обрабатывающий запрос, добавляет свои интервалы с тем же идентификатором трассировки, а такая система, как Jaeger, отображает их на одной временной шкале.

Наблюдаемость и мониторинг#

Мониторинг моделей отслеживает известные виды сбоев с помощью заранее заданных метрик, панелей мониторинга и порогов оповещения, например частоты ошибок выше 1% или задержки инференса выше целевого значения. Наблюдаемость — более широкое понятие: она позволяет расследовать непредвиденные сбои, анализируя подробную телеметрию задним числом по клиенту, версии модели, камере или любому другому атрибуту. В руководстве Google SRE мониторингу предлагается отвечать на два вопроса — что сломалось и почему; расследование переходит от первого ответа ко второму, опираясь на все три типа сигналов:

Объяснимый ИИ — отдельная область, которая объясняет, почему модель сформировала конкретный результат на основе входных признаков или внутренних активаций; сведения об атрибуции можно записывать как ещё один сигнал.

Наблюдаемость систем машинного обучения#

Системы машинного обучения часто дают сбои незаметно: модель компьютерного зрения может отвечать HTTP 200 на каждый запрос, хотя качество предсказаний ухудшается из-за перемещения камеры, изменения освещения или появления нового товара. Поэтому наблюдаемость ML дополняет стандартные сигналы сервиса телеметрией данных и предсказаний. Команды записывают статистику входных данных, например размер и яркость изображения, чтобы обнаруживать дрейф данных, отслеживают распределение предсказаний — например, число объектов каждого класса, пустые результаты и среднюю уверенность — и рассчитывают точность по сегментам после поступления меток эталонной разметки, часто через несколько дней. Во время обучения обратные вызовы передают графики потерь, метрики и данные об использовании системы для каждого запуска в инструменты отслеживания экспериментов, такие как TensorBoard и MLflow. В приложениях с ИИ-агентами и большими языковыми моделями трассировки фиксируют каждый запрос, этап извлечения данных, вызов инструмента и ответ; семантические соглашения OpenTelemetry GenAI стандартизируют такие атрибуты, как gen_ai.usage.input_tokens, чтобы счётчики токенов и стоимость можно было сопоставлять между инструментами.

У каждой выделенной конечной точки на платформе Ultralytics встроен мониторинг развёртывания: карточки с числом запросов, частотой ошибок и задержкой p95; вкладка Logs с уровнями серьёзности и фильтром Errors для записей об ошибках и предупреждениях; а также статистика предсказаний с графиками наиболее частых классов, средней уверенности во времени, числа предсказаний на изображение и времени инференса модели, отдельно от задержки запроса. Падение уверенности или изменение наиболее частых классов будет заметно на графиках, даже если все запросы завершаются успешно.