Classical software observability rests on three signal types that emerged from distributed systems engineering at companies like Google, Netflix, and Twitter between roughly 2010 and 2018. Each captures something the others miss.

Logs are timestamped records of discrete events — a request arrived, a function was called, an exception was thrown. They are the most granular signal and the most expensive to store at scale. Metrics are numerical measurements aggregated over time: requests per second, p99 latency, error rate. They are cheap to store and fast to query, but they compress detail. Traces follow a single request through every service it touches, recording timing and context at each hop. They are the primary tool for diagnosing latency in microservice architectures.

All three were designed for software that does exactly what its code says. Call function X with input Y, get output Z every time. AI inference breaks this contract: the same input can produce different outputs across model versions, the "function" is a billion-parameter statistical approximation, and the failure mode is not an exception thrown — it is a quietly wrong answer that looks perfectly normal from the outside.

AI observability extends the classical three pillars with signal types that are specific to statistical models in production. The field is young — the term was not widely used before 2021 — but a consensus set of additional dimensions has emerged from the work of teams at organizations including Uber, Lyft, Google Brain, and a wave of dedicated tooling companies.

Data and feature monitoring tracks the statistical properties of inputs flowing into the model at inference time and compares them against the distribution seen during training. If a model was trained on loan applications from applicants aged 25–60 and begins receiving applications predominantly from applicants aged 18–22, a statistical test — typically Population Stability Index or Jensen-Shannon divergence — will flag the shift before accuracy degrades visibly.

Prediction monitoring tracks the distribution of the model's outputs. If a classification model begins emitting one class far more frequently than during validation, that shift is often a leading indicator of a data or model problem even before ground-truth labels arrive.

Model performance monitoring tracks accuracy, precision, recall, or task-specific metrics against ground truth as labels become available. The challenge is label latency: ground truth for a credit decision may not arrive for 30–90 days. Much of the practice of AI observability is about what to monitor in the absence of immediate ground truth.

In a mature ML platform — Google's internal systems, Meta's PyTorch-based production infrastructure, or the open-source MLflow and Weights & Biases ecosystems — observability is implemented in layers. The lowest layer is infrastructure telemetry: GPU utilization, memory, network I/O, pod health in Kubernetes. The second layer is serving telemetry: request rate, latency percentiles, error codes from the model server (TorchServe, Triton Inference Server, or a custom FastAPI wrapper are common). The third layer is model telemetry: logged inputs and outputs, feature statistics, prediction distributions. The fourth layer, increasingly common since 2022, is quality telemetry: automated evaluation of outputs using secondary models, human-in-the-loop review pipelines, and feedback signals from downstream systems or users.

Each layer feeds different stakeholders. Infrastructure telemetry goes to SRE teams. Serving telemetry goes to platform engineers. Model telemetry goes to ML engineers and data scientists. Quality telemetry goes to everyone, including product managers and compliance teams. Building a coherent observability stack means deciding what to collect at each layer, where to store it, and who needs to see it in what time frame.

Through 2023 and into 2024, large language models moved from research artifacts to production dependencies at a pace that outran the observability tooling designed for classical ML. A regression model producing a continuous score is relatively straightforward to monitor statistically. A language model producing free-form text raises harder questions: how do you detect drift in a 512-token output? How do you define a distribution over natural language? How do you monitor for hallucination at scale without reading every response?

The emerging answers involve LLM-as-evaluator architectures — using a second language model to score the outputs of the first — combined with deterministic checks for factual anchoring, citation accuracy, and format compliance. Companies including Arize AI, Weights & Biases, LangSmith, and Honeycomb have built tooling specifically for this layer. The field is moving fast, and the vocabulary and practices covered in this module are the stable foundation beneath that fast-moving surface.

Drift detection begins with a reference distribution — typically the feature statistics from the training or validation dataset — and compares incoming production data against it. Several statistical tests have become standard tools for this comparison.

The Kolmogorov-Smirnov (KS) test compares two continuous distributions by measuring the maximum absolute difference between their empirical cumulative distribution functions. It requires no assumptions about the underlying distribution shape and is sensitive to changes in both location and spread. It is the most commonly used test for continuous features in production ML monitoring systems.

The Population Stability Index (PSI) originated in credit risk modeling in the 1990s and remains widely used in financial services AI. It measures the shift in a feature distribution by bucketing values and comparing bucket proportions between reference and production populations. A PSI below 0.1 is generally considered stable; between 0.1 and 0.2 warrants investigation; above 0.2 indicates significant shift. PSI's interpretability — and the fact that it maps directly to regulatory reporting conventions — explains its persistence despite more statistically principled alternatives.

The Jensen-Shannon (JS) divergence is a symmetric, bounded version of KL divergence that measures how much two probability distributions differ. Unlike PSI, it handles continuous distributions natively without bucketing. It is increasingly used in ML monitoring libraries including Evidently AI and WhyLabs, which both launched production-ready open-source tooling in 2021.

Monitoring each feature independently misses an important failure mode: the joint distribution of features can shift even when each individual feature looks stable. A fraud model trained on transaction data where high-value purchases and late-night activity are correlated may behave poorly in a world where that correlation has broken down — even if the marginal distributions of transaction value and time-of-day look unchanged.

Detecting multivariate drift requires different tools. The Maximum Mean Discrepancy (MMD) test operates in a kernel-induced feature space and can detect shifts in the joint distribution without specifying which features are involved. It is computationally expensive but powerful for high-dimensional data. Domain classifier drift detection trains a binary classifier to distinguish reference from production data — if the classifier achieves significantly above-chance accuracy, the distributions have diverged in some detectable way. Google's TFX platform and Arize AI both implement variants of this approach.

A more recent approach, gaining adoption since 2022, uses learned data representations: pass inputs through an encoder (often the early layers of the production model itself) and monitor drift in the embedding space rather than the raw feature space. This detects semantically meaningful shifts even in high-dimensional inputs like text and images where raw feature statistics are uninformative.

Monitoring the distribution of model outputs is distinct from monitoring inputs, and in many ways more directly actionable. If a binary classifier begins predicting the positive class at 35% instead of its historical 18%, that shift is a strong signal that something has changed — whether in the inputs, the model, or the deployment environment. Output drift monitoring does not require access to ground truth labels and can be implemented immediately upon deployment.

For regression models, tracking the mean, variance, and percentile distribution of predicted values against a reference window is straightforward. For classification models, tracking class probability distributions and predicted class proportions provides equivalent signal. For ranking models, tracking the distribution of scores at the top-k positions detects the most operationally important shifts.

The limitation of output drift monitoring is that it is a lagging indicator relative to input drift: by the time prediction distributions shift meaningfully, the model has already been producing degraded outputs. It is most useful as a confirmation signal paired with upstream input monitoring, and as a canary metric for operational teams who do not have direct access to feature-level telemetry.

Detection without response is just surveillance. A production ML system needs a defined protocol for what happens when drift is detected, calibrated to the severity of the shift and the business impact of the model's decisions.

At the first tier — minor drift within warning thresholds — the appropriate response is typically increased logging fidelity and human review of a sample of recent predictions. At the second tier — drift exceeding action thresholds — common responses include model rollback to an earlier version, switching to a more conservative fallback model (often a simpler, more robust baseline), or temporarily routing traffic to human reviewers. At the third tier — severe or rapid drift — the model may need to be taken offline entirely until retraining on current data is complete.

Netflix's 2022 engineering blog described a tiered response system for their recommendation models that automated the first two tiers while requiring human sign-off for the third. The key insight from that system: automating the response to minor drift actually made teams more willing to set sensitive detection thresholds, because they did not face the prospect of an alert triggering a manual escalation at 2am for every minor fluctuation.

ML logging decisions involve four fundamental trade-offs: completeness versus storage cost, granularity versus privacy, immediacy versus throughput impact, and structure versus flexibility. Getting these right requires thinking forward — imagining the investigations you might need to conduct — rather than backward from what is easy to implement today.

At minimum, a production ML system should log: the timestamp of every inference, a unique prediction ID, the model version serving the request, and the model's output. This minimal record enables volume monitoring, version attribution, and output distribution tracking. It is not sufficient for diagnosing most production problems.

The next tier adds input feature values — or a hash or summary of them, if full feature logging is cost-prohibitive or privacy-constrained. This enables input drift detection, feature importance debugging, and the ability to replay historical inferences against a new model version. Uber's Michelangelo, as noted in Lesson 1, built this into the serving layer from day one; teams that did not find themselves unable to diagnose model behavior during the pandemic distribution shifts of 2020.

The highest tier adds contextual metadata: user cohort, geographic region, product surface, A/B experiment assignment, and any contextual signals that might stratify model behavior. This data is often more valuable than the features themselves for diagnosing population-level performance differences — the night-shift versus day-shift discrepancy in the MIT hospital study would have been detectable from a single "shift" metadata field.

High-volume serving systems — a recommendation model processing tens of millions of requests per day — cannot log every inference in full fidelity without incurring prohibitive storage costs. Sampling is necessary, but the sampling strategy matters enormously for what the logs can tell you.

Random sampling at a fixed rate (e.g., 1% of all requests) is the simplest approach and produces a statistically representative sample for distribution monitoring. Its weakness is that rare but important events — edge cases, high-confidence wrong predictions, adversarial inputs — are underrepresented proportionally to their rarity.

Stratified sampling ensures that important subpopulations — demographic groups, product segments, geographic regions — are sampled at rates sufficient to support disaggregated monitoring. This is increasingly important for AI fairness monitoring, where an overall sample might look healthy while a minority subgroup experiences severe degradation.

Anomaly-based sampling preferentially logs predictions that are unusual in some way: high model uncertainty, inputs far from the training distribution, outputs near decision boundaries. This disproportionately captures the cases that are most likely to be problematic and most informative for model improvement. Google's production ML systems described in their 2018 "Rules of Machine Learning" paper use variants of this approach.

Systematic high-value sampling logs 100% of predictions for high-stakes or high-value cases — large transactions, high-acuity medical cases, predictions that will be acted on immediately — while sampling more lightly from routine cases. This prioritizes logging fidelity where the cost of a wrong prediction is highest.

Full-fidelity feature logging is often impossible or inadvisable. Medical features are protected under HIPAA; financial features are regulated under GDPR's right to explanation provisions in the EU; biometric features may be restricted by state laws like Illinois's BIPA. These constraints are not obstacles to observability — they are design parameters.

Common privacy-preserving logging approaches include: logging feature statistics (mean, variance, percentiles) rather than individual values; logging hashed or tokenized versions of sensitive identifiers; logging in an encrypted form that requires key access to read; and separating the feature log from the prediction log with different access controls so that the union of the two tables is only joinable by authorized analysts.

The GDPR's Article 22 provisions on automated decision-making have an important interaction with ML logging: if your system makes decisions with significant legal or similarly significant effects on individuals using solely automated processing, you may be required to log the basis of those decisions in a form that supports human review. This is a regulatory requirement for observability, not a technical choice.

Unstructured logs are nearly useless for ML diagnostics at scale. A production ML logging schema should be structured (JSON or Parquet, not free text), versioned (include a schema version field), and designed with join keys in mind. The prediction ID must be stable and globally unique. If you use a feature store, log the feature retrieval query alongside the feature values so you can diagnose feature serving errors independently of model errors. If you serve multiple model versions simultaneously via A/B or canary routing, the model version and routing decision must be logged with every prediction.

MLflow, introduced by Databricks in 2018, was among the first open-source tools to enforce structured experiment and run logging for ML workflows. Its influence on production logging practices — particularly the emphasis on logging hyperparameters, metrics, and artifacts as first-class objects — is visible in Vertex AI Experiments, Azure ML, and SageMaker Experiments, all of which adopted similar schemas.

Alert fatigue is a documented failure mode in both traditional SRE and ML operations. When monitoring systems generate too many alerts — or alerts with insufficient context — on-call engineers begin ignoring them. A 2023 survey by PagerDuty found that 62% of on-call engineers reported receiving alerts they considered uninformative at least weekly; 31% reported actively suppressing alert channels during periods of high volume. In ML systems, where many alerts are statistical in nature and do not correspond to discrete errors, this problem is more acute.

Effective ML alerts share several properties. They are actionable: each alert has a defined set of actions that can be taken in response, documented in a runbook. They are routed: they reach the person or team with the authority and context to act, not just the person who happens to be on call for infrastructure. They are contextualized: they include not just the raw metric value but the baseline, the trend, the affected model version, and the affected population segment. They are tiered: severity levels distinguish between "investigate during business hours" and "wake someone up now."

The Prometheus and Alertmanager stack, widely used for infrastructure monitoring, supports all of these properties and has been extended for ML monitoring by tools like Evidently AI (which generates drift reports that can be exported as Prometheus metrics) and Grafana ML, which added ML-specific alert condition types in 2022.

For high-stakes AI systems — medical devices, credit decisions, legal document analysis — monitoring is not sufficient without human review capacity. The question is how to design review pipelines that scale with prediction volume and provide actionable signal back into the model development loop.

The standard architecture involves a queue-based review system: predictions flagged by monitoring rules (high uncertainty, anomalous inputs, specific content categories) are routed to a review queue where human reviewers label the output as correct, incorrect, or ambiguous. These labels serve two purposes simultaneously: they generate immediate quality signal for the monitoring dashboard, and they accumulate as training data for the next model version.

Scale Control, acquired by Scale AI in 2021, and Labelbox both offer production review pipeline tooling that integrates this dual-purpose design. Google's data labeling service, launched as part of Vertex AI in 2021, builds the training data feedback loop directly into the annotation interface: reviewed production predictions can be added to the training dataset in one step.

The most sophisticated observability infrastructure is wasted if its outputs do not feed back into model improvement. Closing the feedback loop means building a pathway from production observations — drift detections, error analyses, human review labels — to model retraining and redeployment.

The simplest feedback loop is manual: data scientists review monitoring dashboards on a cadence, decide when retraining is warranted, trigger a retraining job, evaluate the new model offline, and deploy if it passes. This loop typically operates on weeks-to-months timescales and is appropriate for models where the deployment cost is high and the production distribution changes slowly.

Continuous training pipelines automate portions of this loop. Google's TFX (TensorFlow Extended) framework, described in a 2017 KDD paper, pioneered the automated retraining pipeline in production: new data meeting quality criteria is automatically added to the training set, a retraining job is triggered on a schedule or by a drift detection event, the new model is evaluated against held-out production data, and if it passes a comparison threshold against the deployed model, it enters a staged rollout. Meta described a similar architecture for their ad ranking models in a 2021 engineering blog post, noting that continuous training reduced model staleness from weeks to hours for their highest-velocity use cases.

Two deployment patterns work in direct support of observability by structuring how new model versions are introduced to production traffic.

In a canary deployment, a new model version receives a small percentage of live traffic — typically 1–5% — while the current version serves the rest. Monitoring compares the canary's behavior against the baseline in real time. If the canary's metrics degrade or diverge, traffic is routed back to the baseline before the impact is visible to most users. Canary deployments require that your monitoring infrastructure can disaggregate metrics by model version — which is why model version logging, discussed in Lesson 3, is a prerequisite for this pattern.

In shadow mode (also called dark launch or mirror testing), the new model receives a copy of live traffic and produces predictions, but those predictions are not served to users. Instead, they are logged and compared against the production model's predictions offline. Shadow mode enables testing a new model against real production traffic without any user-facing risk. It is particularly valuable for LLM applications where offline evaluation benchmarks are known to be poor predictors of production behavior — a finding documented by researchers at Stanford and DeepMind in separate 2023 papers on the gap between benchmark and production performance of language models.

Technical infrastructure for observability is necessary but not sufficient. The organizational practices around it — who reviews dashboards, how incidents are documented, whether post-mortems generate systemic improvements — determine whether monitoring creates learning or just records failure.

The blameless post-mortem practice, imported into ML teams from SRE culture, is particularly valuable. When a production ML incident occurs, the post-mortem focuses on what system properties made the incident possible and what changes would prevent recurrence — not on who made a mistake. The output is a set of action items that improve the system: new monitoring signals, tightened thresholds, improved runbooks, additional human review checkpoints. Google's Site Reliability Engineering book (Beyer et al., 2016) codified this practice, and it has been adopted by ML platform teams at Airbnb, Spotify, and Twitter (now X) as they built out production ML operations functions.