Observability

La observabilidad es la capacidad de comprender qué ocurre dentro de un sistema de software a partir de la telemetría que emite —principalmente registros, métricas y trazas—, lo suficiente como para responder a nuevas preguntas sobre su comportamiento sin desplegar código nuevo. El término procede de la teoría de control, donde Rudolf Kálmán definió en 1960 un sistema como observable si se puede determinar su estado interno a partir de sus salidas. Los equipos de software lo adoptaron en la década de 2010, cuando los sistemas se dividieron en numerosos servicios y los fallos dejaron de coincidir con los previstos en los paneles de control. En los sistemas de aprendizaje automático, la observabilidad también abarca los datos y las predicciones: qué entradas recibe un modelo, qué genera, con qué confianza y cómo cambian ambas cosas con el tiempo.

Registros, métricas y trazas#

Tres tipos de telemetría, a menudo llamados los pilares de la observabilidad, responden a preguntas distintas:

• Métricas: Series temporales numéricas, como la tasa de solicitudes, la tasa de errores, los percentiles de latencia, la memoria y el uso de GPU. Son baratas de almacenar y adecuadas para paneles de control y alertas. El libro de ingeniería de fiabilidad de sitios de Google establece cuatro señales de oro que deben medirse para cada servicio: latencia, tráfico, errores y saturación.
• Registros: Entradas de eventos individuales con marca de tiempo; son más útiles cuando están estructuradas como JSON con campos como el ID de solicitud, la versión del modelo y el tamaño de la entrada, para poder filtrarlas y contarlas.
• Trazas: El recorrido de una solicitud por todos los servicios que toca, registrado como un árbol de tramos, cada uno con nombre, hora de inicio, duración y atributos, que muestra dónde empleó su tiempo la solicitud.

OpenTelemetry, creado en 2019 mediante la fusión de los proyectos OpenTracing y OpenCensus, proporciona API, SDK y un protocolo de transmisión (OTLP) independientes del proveedor para las tres señales. Los sistemas de almacenamiento, como Prometheus, Grafana y Jaeger, las guardan y muestran. Este ejemplo traza una solicitud de clasificación de imágenes con el SDK de OpenTelemetry para Python y registra un tramo principal para la solicitud y un tramo secundario para cada etapa:

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

En una CPU Apple M5 Pro, imprime un tramo preprocess de 1,0 a 1,4 ms y un tramo inference de 7 a 9 ms, ambos con predict como tramo principal, y un tramo predict de 8 a 10 ms. Así, la traza atribuye al modelo la mayor parte del tiempo de la solicitud. Al exportar los tramos mediante OTLP, cada servicio que gestiona una solicitud añade tramos con el mismo ID de traza, y un sistema de almacenamiento como Jaeger los representa en una única cronología.

Observabilidad frente a monitorización#

La supervisión de modelos busca modos de fallo conocidos mediante métricas, paneles de control y umbrales de alerta predefinidos, como una tasa de errores superior al 1 % o una latencia de inferencia que supera el objetivo. La observabilidad es una capacidad más amplia que permite investigar fallos imprevistos, segmentando a posteriori la telemetría detallada por cliente, versión del modelo, cámara o cualquier otro atributo. El libro de SRE de Google plantea que la supervisión debe responder a dos preguntas —qué falla y por qué—, y la investigación pasa de la primera respuesta a la segunda mediante las tres señales:

La IA explicable es un campo distinto que explica por qué un modelo generó un resultado concreto a partir de sus características de entrada o activaciones internas; sus atribuciones se pueden registrar como una señal más.

Observabilidad para el aprendizaje automático#

Los sistemas de aprendizaje automático suelen fallar sin avisar: un modelo de visión artificial puede responder a todas las solicitudes con HTTP 200 mientras sus predicciones empeoran porque se ha movido la cámara, ha cambiado la iluminación o ha aparecido un producto nuevo. Por eso, la observabilidad de ML añade telemetría sobre los datos y las predicciones a las señales habituales del servicio. Los equipos registran estadísticas de entrada, como el tamaño y el brillo de las imágenes, para detectar el desplazamiento de datos; siguen las distribuciones de predicciones, como el recuento de clases, los resultados vacíos y la confianza media; y calculan la precisión por segmento cuando llegan las etiquetas de referencia, a menudo días más tarde. Durante el entrenamiento, las devoluciones de llamada envían las curvas de pérdida, las métricas y el uso del sistema de cada ejecución a herramientas de seguimiento de experimentos, como TensorBoard y MLflow. En las aplicaciones de agentes de IA y modelos de lenguaje grandes, las trazas registran cada instrucción, paso de recuperación, llamada a herramienta y respuesta; las convenciones semánticas GenAI de OpenTelemetry normalizan atributos como gen_ai.usage.input_tokens para que los recuentos y costes de tokens coincidan entre herramientas.

Cada endpoint dedicado de Ultralytics Platform incorpora monitorización de despliegues integrada: tarjetas con el número de solicitudes, la tasa de errores y la latencia p95; una pestaña Registros con niveles de gravedad y un filtro Errores para las entradas de error y advertencia; y estadísticas de predicciones que muestran en gráficos las clases principales, la confianza media a lo largo del tiempo, las predicciones por imagen y el tiempo de inferencia del modelo, por separado de la latencia de las solicitudes. Una curva de confianza descendente o un cambio en las clases principales se refleja en esos gráficos aunque todas las solicitudes se procesen correctamente.