Monitoring
115 bites tagged Monitoring — interview questions with model answers, and 60-second explainers.
Front-end performance budgets
A performance budget is an enforced limit on metrics like Core Web Vitals and bundle size, checked in CI to fail builds that regress. Performance governance.
Golden signals for capacity planning
Monitor the four golden signals, latency, traffic, errors, and saturation, from day one, watching percentiles and saturation to forecast scaling. Core observability fundamentals.
Core components of Prometheus
Server scrapes targets found via service discovery, stores samples in a local time-series database, with Alertmanager and exporters as helpers. understanding Prometheus's pull model and TSDB.
Symptom-based vs cause-based alerting
Symptom alerts fire on user-visible impact, cause alerts on internal conditions; page on symptoms to cut noise and catch unforeseen failures. Alerting philosophy and pager hygiene.
Black-box vs white-box monitoring for legacy apps
Black-box probes from outside, white-box reads internal state; start black-box for fast user-facing signal. Pragmatic monitoring strategy. Choosing white-box first on an uninstrumented system or ignoring black-box blind spots.
Why use latency percentiles over the average?
Averages hide the tail and are skewed by outliers, so most users can suffer while the mean looks fine; use percentiles; prioritize p99 when tail users are high-value or fan-out… understanding of latency distributions and tail behavior.
What are the Four Golden Signals?
Name latency, traffic, errors, and saturation; explain each briefly; describe measuring latency as a distribution separating success from failure. knowledge of the core user-facing monitoring signals.
Observability vs Monitoring
Monitoring watches predefined metrics and alerts on known failure modes you anticipated. Observability is the property of being able to ask new questions about a system's internal state from its outputs, letting you debug unknown failures you never predicted…
Detecting data drift on a continuous feature
Data drift is when serving feature distributions shift from training; detect with a Kolmogorov-Smirnov test comparing distributions; a small p-value signals drift to alert on. input distribution change in production.
Alerting on under-replicated Deployments
Write an alerting rule comparing kube_state_metrics available vs desired replicas with for: 5m, Prometheus evaluates and fires to Alertmanager, which dedupes/routes/notifies. Prometheus alerting pipeline.
PromQL for top 5 CPU-consuming pods
Apply rate() to the counter over 15m, sum by pod to combine containers, then wrap in topk(5); rate handles counter resets. PromQL on counters.
Auto-discovering app pods for Prometheus scraping
Use kubernetes_sd_configs with role pod, relabel on pod annotations like prometheus.io/scrape to filter, and set path and port; with the Operator use a PodMonitor or ServiceMonitor. Kubernetes service discovery in Prometheus.
kube-state-metrics versus node-exporter
Kube-state-metrics exposes API object state (deployment replicas, pod phase, restarts) from the control plane, while node-exporter exposes OS-level hardware metrics (CPU, memory, disk) per… Distinguishing object-state from host metrics.
Zero-downtime model updates with blue-green or canary
Blue-green swaps full traffic after validation, canary ramps a small slice; both need health, latency, and quality monitoring plus instant rollback. safe rollout design. only watching system metrics, not model quality.
Detecting and responding to model and concept drift
Define drift, pick a metric like PSI or falling AUC against labels, then investigate, retrain, validate. production monitoring. assuming static accuracy or retraining blindly without diagnosing the cause.
Design drift detection and retraining for a CV model.
Monitor input and prediction distributions plus delayed labels, detect data and concept drift, trigger an automated retrain-validate-deploy pipeline with versioning and rollback. MLOps drift handling.
Difference between metrics and logs
Metrics are aggregated numeric time series good for trends and alerting; logs are discrete timestamped event records good for detailed root-cause analysis. observability fundamentals.
Design auto drift detection and retraining
Capture inputs and predictions, compute data and concept drift metrics on a schedule, alert on threshold breach, and trigger a retraining and redeploy pipeline. closed-loop MLOps design.
Rightsizing an underutilized VM fleet safely
Gather multi-week percentile metrics across CPU, memory, network and disk; pick smaller or right-family types; roll out gradually with monitoring. data-driven cost optimization. resizing on average CPU alone.
Monitoring with SLOs and error budgets
Define SLIs from the user's view, set SLO targets, derive an error budget, and alert on burn rate rather than raw thresholds. SRE reliability targets. paging on every CPU blip with no link to user impact.
Diagnose 100% CPU on a managed database
Correlate the spike with deploys and traffic, find top queries via the engine's views, inspect plans for missing indexes, then tune before scaling. structured DB triage. scaling up without finding the offending query.
Centralized logging across microservices
Ship structured logs from every service into a central searchable store, then propagate a correlation ID through all hops to trace one request. aggregating and correlating logs. grepping per-host files with no shared ID.
Distributed tracing for serverless apps
Propagate a trace context through every hop, instrument with OpenTelemetry or X-Ray, capture spans including the database, and correlate traces with structured logs. end-to-end observability. per-service logs, no correlation.
Diagnosing model degradation over time
Name it model drift, split data vs concept drift; diagnose by comparing distributions and ruling out pipeline bugs; fix via monitoring and retraining. MLOps maturity around drift. Blind retraining before diagnosis.
Get Monitoring bites daily.
Five a day, five minutes, offline. With quizzes so it sticks.
Open testing — you’ll join as an early tester.