AI observability is difficult because a production AI system can be technically available while the output quality is degrading. The current AI-300 track treats observability as part of GenAIOps and MLOps rather than as a dashboard added after deployment. Operators need signals that explain infrastructure health, application behavior, model quality, cost, safety, and user impact without pretending that one metric can represent all of them.
The familiar ideas behind logging and monitoring on Azure still matter, but AI systems add a second class of evidence: prompts, retrieved context, model versions, inference parameters, evaluation scores, feedback, drift, and trace relationships. A 200 response with low latency can still be a failed user interaction if the model hallucinated, ignored grounding, exposed sensitive data, or selected the wrong tool.
The practical mental model is therefore layered. Infrastructure telemetry explains whether the service can run. Application telemetry explains which path was executed. AI-quality telemetry explains whether the result was useful and safe. Business telemetry explains whether users achieved the intended outcome. Production observability connects those layers rather than collapsing them into one health percentage.
Availability is necessary and insufficient
A model endpoint can answer every request and still fail the product objective. Traditional uptime, CPU, memory, network, and HTTP error metrics reveal platform health, but they do not show whether retrieved evidence was relevant or a generated answer was correct.
Define service objectives at several levels. Latency and availability protect responsiveness. Quality metrics protect answer usefulness. Safety metrics protect policy. Business metrics protect the workflow the AI system is meant to improve.
When one layer changes, operators should be able to ask whether the change propagates upward. A slower vector query may increase user latency; a new model may improve quality while increasing cost; a prompt change may preserve latency and reduce task success.
Production baselines should include request mix, not only metric averages. A system handling mostly simple questions can look healthy until a new customer segment starts asking longer, multilingual, or tool-heavy requests. Segment telemetry by use case, model route, geography, and customer tier where that context matters, so a distribution shift does not disappear inside one global latency or quality number.
Tracing makes component boundaries visible
Modern AI applications often contain several stages: classify intent, retrieve data, call a model, invoke a tool, apply guardrails, and format the answer. A single request metric hides where the behavior changed.
Trace each important stage with stable request identifiers and component versions. Record enough input/output metadata to explain the path while respecting privacy and data-retention requirements.
Distributed traces are especially useful when failures are intermittent. If only some prompts trigger a slow tool or weak retrieval path, averages can remain healthy while user complaints grow.
Trace sampling needs a policy. Capturing every request can be expensive and sensitive, while sampling too aggressively can miss rare failures. Keep full traces for errors, high-risk actions, or controlled cohorts, then sample routine success traffic at a rate that preserves trend visibility. The sampling decision itself should be versioned because changing it can make an apparent quality improvement nothing more than a measurement change.
Quality metrics need a reference question
Accuracy is meaningless until the evaluation target is defined. Retrieval quality can use recall, precision, ranking, or groundedness-oriented measures. Generated answers can be scored for factuality, relevance, completeness, safety, or task success.
Select metrics that match the use case. A summarizer and a support agent do not need the same score. A legal extraction pipeline may value precision more than creativity; a brainstorming assistant may tolerate broader variation.
Quality monitoring should also record uncertainty. LLM-as-a-judge scores, human review, and business outcomes are evidence with different reliability. Treat evaluation signals as measurements that require calibration, not as perfect truth.
Evaluation metrics also need threshold ownership. A groundedness score below 0.8 means little unless the team has calibrated what that threshold implies for the application and what action follows. Reviewers should know which metrics are release gates, which are diagnostic indicators, and which are research signals that should never trigger automatic rollback without human context.
Drift can occur without model drift
Input distributions can change because users ask different questions, source documents change, product catalogs evolve, or the application reaches a new region. Retrieval corpora can become stale while the model itself remains identical.
Prompt drift and tool drift matter too. A prompt template, system instruction, API schema, or downstream service can change enough to alter behavior even when the deployed model version does not.
Observability should therefore capture versions across the application graph. If quality changes after a release, the team needs to know whether the model, prompt, retriever, data, tool, or policy changed.
Production drift should be categorized before remediation. Data drift means inputs changed; concept drift means the relationship between input and desired output changed; application drift can come from prompts, tools, or retrieval; infrastructure drift can change latency and capacity. Using one generic drift alert for all four makes the operator guess which component to investigate.
Data quality is part of AI observability
The general discipline of data-quality accountability matters because many AI failures originate before inference. Missing metadata, duplicate documents, stale records, malformed training examples, or mislabeled evaluation data can produce bad outcomes that look like model problems.
Monitor freshness, completeness, schema change, volume, and representative data-quality rules on inputs that influence the model or retriever.
Ownership should be explicit. The AI team can detect a stale source and may not own the business system that must correct it. Alerts without a remediation owner simply convert hidden defects into visible defects.
Observability pipelines should watch the evaluators too. A failed judge model, stale scoring prompt, broken trace parser, or changed sampling rule can make the quality dashboard look better or worse while production behavior is unchanged. Treat observability configuration as production code with version history, tests, and a small set of known examples that verify scoring remains calibrated.
Cost is an operational signal
Token use, GPU/CPU utilization, request volume, retrieval depth, model size, retry behavior, and long context windows can change cost substantially without changing uptime.
Track unit economics such as cost per successful task, cost per thousand requests, or cost per evaluated conversation. Raw monthly spend is too slow and too disconnected from behavior to explain one production regression.
Cost anomalies can be symptoms of quality defects. A tool loop, oversized prompt, retry storm, or retrieval fan-out may increase both latency and spend before users report a problem.
Cost alerts should use both absolute and normalized views. A large increase in spend may be healthy if traffic doubled, while stable monthly spend can hide worsening unit economics if task volume fell. Track tokens and compute per successful workflow, then compare with request volume and quality so operators can tell growth from inefficiency.
Safety and policy need their own evidence
Guardrail decisions, blocked requests, sensitive-content detections, policy overrides, jailbreak indicators, and human escalations should be observable without logging sensitive content indiscriminately.
Measure false positives as well as successful blocking. An overaggressive control can make a safe application unusable and encourage teams to bypass the guardrail.
Retain enough metadata to reconstruct why a request was blocked or allowed. Policy that cannot explain its decision is difficult to improve and difficult to defend.
Safety telemetry also needs privacy boundaries. Redact or hash identifiers when raw content is unnecessary, limit who can access captured prompts and responses, and apply shorter retention to sensitive traces where policy requires it. Observability that creates a second uncontrolled copy of production prompts can introduce more risk than the monitoring program removes.
Alerts should represent decisions, not raw movement
Alert when a signal crosses a threshold that requires a human or automated response. Small metric fluctuations belong on dashboards; service-objective violations, sustained drift, quality regression, or unexpected spend growth can justify action.
Correlate related symptoms before paging. Latency plus rising retrieval errors means something different from latency plus stable component health and increased request volume.
Define runbooks for quality alerts as carefully as infrastructure alerts. Operators need to know what to compare, which version to inspect, whether rollback is safe, and how to protect users while investigation continues.
Runbooks should distinguish rollback from mitigation. Lowering traffic to an unstable model, disabling one tool, tightening a guardrail, or routing to a safer fallback can protect users while the root cause is investigated. Full rollback is only one response option, and it may be inappropriate when the problem originates in new source data rather than in the release itself.
Observability is proven during change
Deploy a new model, prompt, or retrieval configuration and compare quality, latency, safety, and cost against a known baseline. Use canaries or controlled cohorts when the blast radius is high.
Then test failure: remove a data source, slow a tool, inject malformed input, or simulate stale evaluation data. The monitoring system should show which layer degraded and what user impact followed.
Production observability is mature when teams can answer what changed, which requests were affected, why the behavior changed, and whether rollback restored the service objective—without relying on the engineer who originally built the system.
A final maturity test is whether another engineer can investigate an incident without opening the builder’s notebook. Dashboards, traces, version metadata, runbooks, evaluation history, and ownership should provide enough evidence to reconstruct the system state. If troubleshooting depends on one person’s memory of which prompt or model was probably active, observability has not yet become an operational capability.
