Observability & Logging

Busted

• Alert fatigueWhen so many alerts are noisy or pointless that responders start ignoring them, including the one that matters.
• Alert ruleA saved condition that is checked repeatedly and triggers a notification or incident action when it stays true.
• Alert thresholdThe line a metric has to cross before something notifies you: 'error rate over 2 percent for 5 minutes, page someone'.
• Anomaly detectionAlerting when a signal strays from its learned normal pattern, so expected daily peaks do not need one rigid threshold.
• APM (application performance monitoring)Production monitoring that shows which endpoint, function, or query is eating the time, not just that the app got slow.
• Black-box vs white-box monitoringBlack box asks whether the system works from outside; white box reads its internal metrics and logs to explain what is happening.
• Blameless postmortemA written incident review that asks what made the failure possible and how to prevent a repeat, instead of deciding who to blame.
• BreadcrumbsThe trail of clicks, navigation, requests, and app events recorded before an error, showing how the user reached the crash.
• Burn-rate alertAn alert that pages when failures are using up the service's allowed error budget too quickly.
• Canonical log lineThe one authoritative summary log written when a request ends, with its result, timing, and debugging context.
• Cardinality explosionWhen metric labels combine into millions of separate series, making storage, queries, and the monitoring bill blow up.
• Continuous profilingAn always-on production profiler that lets you see which functions consumed CPU or memory during any past slowdown.
• Correlation IDOne ID attached to a single request and stamped on every log it produces, so you can pull that request's whole story out of the pile.
• Counter / gauge / histogramCounter counts events, gauge shows the current level, histogram shows how measurements are spread across buckets.
• DashboardA saved screen of operational charts and queries, arranged so you can tell whether a service is healthy at a glance.
• Distributed tracingFollowing one request as it hops through every service, so you can see which hop actually made it slow.
• Downsampling (rollup)Keeping recent metrics in fine detail while compressing older history into wider time buckets.
• Error budgetThe failure you are allowed before you break your SLO: 99.9% means 0.1% of requests can fail, and that 0.1% is a budget you spend.
• Error groupingCollapsing thousands of identical crashes into one issue with a counter, so a single bug means a single alert, not 5,000 emails.
• Error rateThe share of operations that failed in a time window: 20 failures out of 10,000 requests is a 0.2 percent error rate.
• Error trackingA service that captures the unhandled and reported exceptions from your live app, groups the duplicates, and tells you which ones hit real users.
• ExporterThe output component of a telemetry pipeline that ships traces, metrics, or logs onward to a backend such as Tempo or an OTLP endpoint.
• Flame graphA profiler picture where the widest stacks are the code paths consuming the most sampled CPU time.
• Golden signalsLatency, traffic, errors, and saturation: the four charts that tell you whether a service is healthy, from the Google SRE book.
• Heartbeat monitoring (dead man's switch)Your scheduled job pings a URL when it finishes. If the ping never arrives, you get paged. Alerting on silence instead of errors.
• High cardinalityA field with a huge number of distinct values, like user_id or a raw URL. Usually workable in traces, ruinous as a metric label.
• InstrumentationThe code that makes your app report on itself: the spans, metrics, and logs you add so there is anything to look at later.
• Latency percentileRanking response times to ask how slow the worst ones are: p95 means 95 percent of requests finished faster than that.
• Live tailStreaming logs as they happen, so you can hit the button and watch the line appear. The hosted version of tail -f.
• Log aggregationShipping logs off every server, container, and function into one searchable place, so you stop SSH-ing into boxes to grep.
• Log drainA pipe that forwards a hosting platform's stdout and stderr logs to an external log service or archive.
• Log levelThe severity tag on a log line (debug, info, warn, error) and the dial that decides which of them actually get written.
• Log parsingPulling named fields out of plain-text log lines so you can filter, count, and group them instead of searching raw sentences.
• Log retentionHow long logs stay searchable before they are archived or deleted. The reason last month's incident has vanished from your log tool.
• Log-based metricA counter or chart created by counting log entries that match a rule, useful when the app does not emit the metric directly.
• MetricA number measured over and over with a timestamp, so you can graph it: requests per second, memory used, errors per minute.
• MTTR / MTTDThe averages for how long incidents go unnoticed and how long service takes to recover, used to find where response is slow.
• ObservabilityBeing able to answer 'why is it broken?' from the data your app already emits, without shipping new code just to find out.
• On-call escalation policyThe rules for paging the primary responder, waiting for an acknowledgement, then paging the next person if nobody answers.
• OpenTelemetry (OTel)The vendor-neutral standard for emitting traces, metrics, and logs, so you instrument once and can swap monitoring tools later.
• OpenTelemetry CollectorA vendor-neutral telemetry middleman that receives, batches, filters, and routes logs, metrics, and traces to backends.
• PII scrubbing (log redaction)Stripping emails, tokens, and card numbers out of logs before they are written, so your log tool is not a breach waiting to happen.
• RUM (real user monitoring)Telemetry collected inside real visitors' browsers, so you see what your actual users hit instead of what your laptop hits.
• RunbookThe step-by-step document linked from an alert, telling the on-call person how to diagnose, mitigate, verify, and escalate the failure.
• SamplingKeeping only a fraction of your traces and logs, say 1 in 100, so the volume and the bill stay sane without losing the picture.
• Service dependency mapA live graph built from traffic or traces that shows which services call each other and where failures or latency travel.
• Severity level (SEV)The number attached to an incident to say how damaging it is and how fast, loudly, and widely the team must respond.
• SLI (service level indicator)The measured reliability number behind an SLO, such as the percentage of valid requests that succeeded or finished fast enough.
• SLO (service level objective)A reliability target you commit to, like '99.9% of requests succeed this month', so system health is a number instead of a vibe.
• SpanOne timed operation inside a trace: a name, a duration, and a parent, drawn as a single bar in the request waterfall.
• Span attributes (tags)Searchable key-value details on a trace span, such as route, cache hit, or retry count, that explain why one operation behaved differently.
• Stack traceThe list of function calls that led to a crash, so you can see exactly which line broke and what called it.
• Structured loggingLogging JSON objects with named fields instead of sentences, so you can filter and group your logs instead of grepping them.
• SymbolicationTurning crash addresses and minified stack frames back into the function names, source files, and line numbers you wrote.
• Synthetic monitoringA robot that regularly uses your production site or API so broken user journeys are found before a real customer reports them.
• TelemetryThe data a running app sends out about itself: logs, numbers, and timings. The raw material every dashboard and alert is built from.
• Telemetry attributeA key-value fact attached to telemetry, such as service, route, or release, that lets you filter and group the data later.
• Throughput (request rate)How much work a system handles per unit of time, such as requests per second or jobs per hour.
• Time-series databaseA database built to store and query timestamped measurements, which is what keeps monitoring charts fast over long time ranges.
• TraceThe linked spans recording one operation end to end, drawn as nested bars so you can see which step ate the time.
• Trace context propagationPassing trace IDs across HTTP, queues, and jobs so one request stays connected as it hops between services.
• Trace IDThe shared ID that ties every timed step of one request into a single trace, even when the work crosses services.
• Uptime monitoringA robot outside your servers that requests your site every minute and yells when it stops answering.
• Wide eventOne rich, structured event that carries nearly everything you would need to explain a request after it finishes.

The territory

30 core terms mapped for this field, ranked by how often builders reach for them. Each one is a future entry. Want to bust one? One entry, one file, one pull request.

• observabilityinferring internal system state from the telemetry a system emits"figuring out why it broke without redeploying" · "o11y"
• telemetrysignals a system emits about its behavior, performance, and health"the data my app reports about itself" · "the numbers coming out of the app"
• structured logginglogs emitted as machine-parseable JSON key-value fields, not prose"logs I can actually search" · "logs as objects instead of sentences"
• log levelseverity tag (debug/info/warn/error) controlling what gets emitted"turn the noisy logs off in prod" · "only show me the bad ones"
• error trackingservice that captures, groups, and alerts on runtime exceptions"tell me when users hit a crash" · "exception inbox"
• correlation IDunique ID stitching all logs from one request together"trace one user's request across services" · "a tag that follows the request"
• stack tracefunction call chain captured at the moment of an error"the wall of text showing where it broke" · "the crash printout"
• metrictimestamped numeric measurement tracking system behavior over time"a number I can graph over time" · "the stat on the chart"
• alert thresholdrule firing a notification when a metric crosses a limit"ping me if errors spike" · "notify me when it gets bad"
• uptime monitoringexternal pings checking your site responds, from outside your infra"is my site down right now" · "something that checks the site every minute"
• health check endpointURL returning OK so load balancers know the app lives"the /healthz thing" · "a page that says the server is alive"
• latency percentileresponse time at a given rank, such as the slowest 5%"p95 / p99" · "not the average, the bad tail"
• traceend-to-end record of one request, built from linked spans"the full journey of one request" · "the timeline for a single request"
• distributed tracingfollowing one request end-to-end across every service it touches"see the whole path of a request" · "which service made it slow"
• spanone timed operation inside a trace, nestable into a timeline"the individual bars in that timing chart" · "one step of the request"
• OpenTelemetry (OTel)vendor-neutral standard for emitting traces, metrics, and logs"instrument once, switch tools later" · "the standard logging/tracing format"
• instrumentationcode added to emit telemetry; auto (agent-injected) or manual"wiring the app up to report things" · "adding the tracking hooks"
• log aggregationshipping logs from all machines into one searchable place"all my logs in one search box" · "central log pile"
• live tailstreaming logs in real time as they happen"watch the logs scroll live" · "follow mode"
• error groupingcollapsing thousands of identical errors into one deduplicated issue"fingerprinting" · "stop 5000 emails for the same bug"
• samplingkeeping only a fraction of traces/logs to cut cost and volume"don't record every single request" · "keep 1 in 100"
• SLO (service level objective)explicit target like "99.9% of requests succeed monthly""the reliability promise" · "how much downtime is acceptable"
• error budgetallowed failure amount remaining before you breach your SLO"how much breakage I can still afford" · "downtime allowance"
• golden signalslatency, traffic, errors, and saturation: the four charts always worth watching"the only four charts I need" · "the standard dashboard set"
• high cardinalityfields with huge numbers of distinct values, like user_id"tagging by user blows up the bill" · "too many unique values"
• RUM (real user monitoring)telemetry collected from actual browsers of actual visitors"real-world speed, not lab tests" · "what it's like on their phone"
• APM (application performance monitoring)tooling that profiles code paths, queries, and endpoints in production"which endpoint and which query is slow" · "the perf x-ray"
• heartbeat monitoring (dead man's switch)alert fires when a scheduled job fails to check in"tell me if my cron didn't run" · "alert on silence"
• log retentionhow long logs are stored before deletion, often tiered hot/cold"how far back can I search" · "keep 30 days then archive"
• PII scrubbing (log redaction)stripping emails, tokens, and card numbers before logs are stored"don't log passwords" · "mask the sensitive fields"

Deeper in the field

• counter / gauge / histogram the three metric shapes: cumulative, point-in-time, distribution
• time-series database storage optimized for timestamped metric points
• cardinality explosion metric costs blowing up from too many label combinations
• flame graph stacked-bar visual showing where CPU time is actually spent
• continuous profiling always-on production profiler sampling CPU and memory
• anomaly detection alerting on deviation from learned normal instead of fixed thresholds
• trace context propagation passing traceparent headers so traces survive service hops
• OpenTelemetry Collector agent that receives, processes, and routes telemetry
• exporter component that sends collected telemetry to a specific backend
• wide event one fat structured event carrying broad request context
• canonical log line single summary log line emitted per request
• downsampling (rollup) compressing old high-resolution metrics into coarser buckets
• log-based metric counter derived by matching a pattern in log volume
• service dependency map auto-generated graph of which services call which
• synthetic monitoring scripted robot journeys run on a schedule against production
• severity level (SEV) incident grading scale driving response urgency
• MTTR / MTTD mean time to recover / detect, the incident speed metrics
• burn-rate alert fires when error budget is being consumed too fast
• alert fatigue responders ignoring alerts because too many are noise
• blameless postmortem written incident review focused on systems, not individuals
• black-box vs white-box monitoring probing from outside versus reading internal state
• span attributes (tags) key-value metadata attached to a span for filtering
• breadcrumbs trail of user actions recorded before an error, for context
• log drain pipe forwarding a platform's logs to an external destination
• on-call escalation policy rules deciding who gets paged, when, and who's next
• runbook step-by-step doc for handling a specific alert or failure
• SLI (service level indicator) measured reliability signal used to evaluate an SLO
• alert rule evaluated condition triggering notifications or incident actions
• dashboard saved visual view combining operational charts, tables, and queries
• telemetry attribute key-value context used to filter, group, and aggregate telemetry
• trace ID identifier shared by every span in one distributed trace
• error rate proportion of operations failing within a defined time window
• throughput (request rate) number of operations handled per unit of time
• log parsing extracting searchable fields from unstructured log messages
• symbolication converting stack addresses into readable functions and source locations