SRE
205 bites tagged SRE — interview questions with model answers, and 60-second explainers.
Log Aggregation: Centralize Your System's Story
Log aggregation funnels scattered logs from many servers into one central, searchable system. It's crucial for debugging distributed systems where one request touches many services.
Time-Series Databases: Optimized for Data Over Time
A Time-Series Database (TSDB) is a database optimized for data where time is the primary key. It's the backbone for monitoring systems, IoT devices, and financial apps. The footgun is using a regular database, which can't handle the unique query load.
Prometheus Exemplars: Link Your Metrics to Traces
Exemplars are like footnotes for your metrics, linking a data point like a latency spike directly to a specific trace ID. This lets you jump from a 'what' on a dashboard to the 'why' in your tracing system.
Telemetry Processors: The Middle of the OTel Pipeline
A Telemetry Processor is a configurable stage in an OpenTelemetry Collector pipeline, sitting between data reception and export. You configure them in config.yaml to act on telemetry data.
Context Propagation: Stitching Microservices Together
Context propagation stitches a user request's journey across microservices by passing a shared ID. It's essential for distributed tracing, letting you see one request flow through many APIs.
OpenTelemetry Resource: The 'Who' of Your Telemetry
An OpenTelemetry Resource is the return address for your telemetry, describing the service instance that produced it. It attaches stable context like service name and version to every signal, enabling filtering.
OpenTelemetry Protocol (OTLP): The Universal Adapter for Telemetry
OTLP is the universal adapter for observability, providing a single vendor-neutral protocol for traces, metrics, and logs. Use it to send data from an OpenTelemetry SDK to a collector.
Span: The Building Block of a Distributed Trace
A Span is a single unit of work in a request's journey, like one leg of a flight. Spans capture the duration and context of individual operations (e.g., a DB query), helping you debug latency in distributed systems.
OpenTelemetry Collector: The Swiss Army Knife for Telemetry Data
The OpenTelemetry Collector is a universal adapter for your telemetry data. It receives data in one format, processes it, and exports it to multiple backends, letting you centralize configuration and avoid vendor lock-in.
OpenTelemetry API: The Stable Interface for Your Code
The OpenTelemetry API provides stable interfaces for your code to generate telemetry. This lets you instrument your application once, while the SDK implementation handles the actual data processing and export, which can be swapped out later.
Error Budget Burndown: Your Service's Reliability Fuel Gauge
An error budget burndown chart is a fuel gauge for your service's reliability. It shows how much 'allowable downtime' you've used, helping you decide when to ship features versus fix bugs. The footgun is ignoring a steep burn rate until it's too late.
SLO Burn Rate: Alerting on Budget Consumption
SLO burn rate measures how fast you're using your error budget. A burn rate of 2 means you're consuming budget twice as fast as allowed. It's used to trigger alerts for both fast outages and slow-burning problems to prevent SLO breaches.
SLO Document: Your Service's Reliability Contract
An SLO document is the source of truth for a service's reliability promises, acting as a formal contract between teams on what 'good enough' looks like. It defines measurable targets for availability and latency, guiding engineering priorities.
SLO Time Windows: Choosing Your Measurement Period
An SLO's time window is the calendar for grading reliability. A short window forces rapid fixes, while a long one smooths out blips for strategic planning. The footgun is using calendar months, which have unequal lengths and complicate budget math.
Error Budgets: The Currency of Reliability
An error budget is the acceptable amount of downtime or errors your service can have over a period. Calculated as (1 - SLO), it's a currency for balancing risk (new features) and reliability work. The main footgun is treating it as a target to spend.
Sampling: Tracing Everything Without Storing Everything
Sampling makes high-volume observability affordable by deciding which traces to keep and which to discard. It's essential in distributed systems where capturing every request is too costly.
Cardinality: The Hidden Cost of Time-Series Metrics
Cardinality is the number of unique label combinations in your metrics. High cardinality, from labels like user IDs, is the silent killer of monitoring systems like Prometheus, exploding memory and cost. The footgun is adding a label with unbounded values.
Pull vs. Push: How Your Metrics Get to the Collector
Push vs. Pull metrics is about who starts the conversation. In a push model (like OTLP), the app sends metrics to a collector. In a pull model (like Prometheus), the collector scrapes metrics from the app. The footgun: pull can miss short-lived jobs.
The Four Golden Signals of Service Monitoring
The Four Golden Signals provide a simple framework for service health: Latency, Traffic, Errors, and Saturation. Use them for top-level dashboards and alerts. The biggest footgun is ignoring saturation, the leading indicator of future latency issues.
Health Checks: Is Your Service Alive or Just Running?
A health check answers 'Can you do your job?', not just 'Are you running?'. Load balancers and orchestrators use this API endpoint to stop routing traffic to sick instances.
Code Instrumentation: Making Your App Observable
Instrumentation is like adding a flight recorder to your app, emitting telemetry about its internal state. It's how you generate traces, metrics, and logs for observability tools. The main footgun is over-instrumenting, creating noisy and expensive data.
SRE Engagement Models: From Gatekeeper to Platform Builder
SRE engagement models define how reliability experts help product teams, evolving from gatekeeping existing services to providing reliable platforms. This applies when scaling an SRE team's impact.
Service Level Agreement (SLA): The Contract Behind Uptime
An SLA is a business contract, not a technical target. It defines the minimum service quality a provider promises a customer, with financial penalties for failure. You see them in every cloud provider contract.
Blameless Postmortems: Fix Systems, Not Blame
A blameless postmortem treats human error as a symptom of a system flaw, not a root cause. It's used after major incidents to find systemic causes and prevent recurrence, assuming everyone acted with good intentions.
Get SRE bites daily.
Five a day, five minutes, offline. With quizzes so it sticks.
Open testing — you’ll join as an early tester.