Module 8 of 12 · 55 min

Observability, Cost, and Performance

Instrument model serving with privacy-conscious logs, metrics, traces, alerts, and cost evidence that connect user outcomes to exact model and runtime identities.

Core concept

By the end

You will be able to

  • Define observable questions and service objectives before selecting telemetry fields or dashboards.
  • Correlate requests, model identities, policy outcomes, errors, latency, resource use, and cost without logging unnecessary content or secrets.
  • Interpret distributions, queueing, saturation, cardinality, sampling, and missing telemetry correctly.
  • Create actionable alerts, investigation views, retention controls, and evidence that supports tuning, capacity, release, and incident decisions.
01

Start with operational questions and objectives

Write the questions operators must answer: Is the right model serving? Are users receiving valid results? Which slices fail? Where is time spent? What is queued or rejected? Which resource is saturated? Did an update change quality, security, cost, or recovery? Can an incident be scoped and reproduced?

Define indicators and objectives for availability, successful outcomes, policy outcomes, latency distributions, queue time, throughput, rejection, error, recovery, and budget. A dashboard without a decision or owner becomes decorative telemetry.

02

Correlate logs, metrics, traces, events, and exact identities

Use a request or run identifier to connect gateway, adapter, inference server, runtime, tool, policy, and application events. Record service and instance identity, exact model and runtime bundle, route, operation, status, error category, policy disposition, input and output size measures, queue and processing time, resource observations, and release identifier.

OpenTelemetry semantic conventions provide shared names and stability metadata for telemetry concepts. Version the convention and application fields you adopt. Do not assume every generative-AI field is stable or available across runtimes; preserve an application-owned core and explicit adapters.

03

Minimize sensitive content and control telemetry access

Default to metadata and derived measurements rather than raw prompts, responses, retrieved documents, credentials, headers, or personal identifiers. If sampled content is necessary for an approved purpose, minimize, redact, encrypt, restrict access, record consent or authority, set short retention, audit use, and test deletion.

Threat-model telemetry pipelines, collectors, exporters, stores, dashboards, alerts, and support bundles. A secure serving path can still disclose data through verbose errors, traces, exception bodies, labels, exemplars, or high-cardinality identifiers.

04

Measure distributions, saturation, and attributable cost

Record latency and size as distributions with suitable histogram resolution or buckets, not only averages. Prometheus documents that precomputed summary quantiles are generally not aggregatable across replicas, while histograms support later aggregation subject to their representation. Preserve counts, failures, and the population behind every percentile.

Measure queue time, time to first output, processing and streaming time, throughput, cancellations, retries, cache behavior, accelerator and host utilization, memory headroom, storage and network activity, and energy or cloud charges where available. Attribute costs by bounded tenant, workload, route, model, and release without using unbounded labels.

05

Alert on symptoms with actionable context

Alert on user-visible objective burn, critical safety or security outcomes, sustained queueing, rejection, errors, memory pressure, unavailable replicas, model-identity mismatch, telemetry loss, cost anomalies, and failed backup or rollback checks. Attach owner, severity, runbook, evidence links, and safe first actions.

Test alert firing, routing, deduplication, suppression, escalation, and recovery. Preserve baseline and deployment annotations so an operator can compare before and after a change. Missing telemetry is a condition to detect, not evidence that the service is healthy.

Practice activity

Build a privacy-conscious observability contract

  1. Write ten operator questions and map each to signals, exact identities, dimensions, owner, decision, and retention.
  2. Define request, model, release, policy, latency, queue, error, saturation, and cost fields with stability and cardinality limits.
  3. Classify every proposed field as required metadata, optional sensitive content, prohibited secret, or derived measurement.
  4. Design latency and size histograms, objective calculations, and cost allocation for three replicas without averaging quantiles.
  5. Create five alerts and paper-test firing, routing, evidence, runbook, escalation, and recovery.

What to produce

  • An operator-question-to-signal matrix and versioned telemetry field contract.
  • A privacy, access, retention, redaction, cardinality, sampling, and deletion review.
  • Objective, distribution, cost, dashboard, and alert fixtures with tested-paper incident and recovery links.

Reflect before continuing

Which telemetry field is easiest to collect but hardest to justify retaining?

Evidence

Sources and verification

Knowledge check

Make it stick.

Pass at 80%

Choose the strongest answer for each question. Your attempts become part of your device-local transcript.

01What should come before dashboard design?
02Which identity is essential for release comparison?
03What is the safest default for prompt and response content in telemetry?
04Why should latency be recorded as a distribution?
05What is wrong with averaging p95 values from multiple summaries?
06What makes an alert actionable?