CCNA Observability Concepts Questions

In a pull model Prometheus initiates each scrape, so a failed connection or timeout directly signals that the target is down. This lets the server detect target failure itself, rather than waiting for the target to push data, satisfying the scenario's requirement for the primary pull-based benefit.

Labels are key-value pairs attached to a metric name; the full set of label values uniquely identifies each time series within Prometheus's TSDB. This satisfies the stem's purpose, distinguishing individual series that share the same metric name.

Storage is a resource metric, not one of the four Golden Signals: latency, traffic, errors and saturation. Those four, from Google's SRE guidance, describe user-facing service health, whereas storage capacity is an underlying infrastructure concern.

Each unique label combination creates a distinct time series held in memory, so ephemeral pods with churning names, IDs or hashes generate vast numbers of short-lived series. This memory overhead, not scrape volume, is the dominant cardinality constraint in dynamic clusters.

Latency as a Golden Signal distinguishes successful-request duration from error duration, so you can break down response time by dependency. If external calls dominate the slow percentile, the latency originates outside the service, directly satisfying the need to isolate external-dependency causation.

Collecting every available metric floods dashboards and alerts with low-value data, obscuring genuine incidents. It also inflates storage, scrape load and licensing costs. Avoiding this preserves signal clarity and controls resource expenditure, satisfying the stem's rationale.

Histograms bucket observations into configurable ranges and expose cumulative counts plus a sum, letting you calculate quantiles such as p95 latency across aggregated series. That distributional view is what latency analysis needs, unlike a gauge or counter, satisfying the requirement to capture request latency distribution.

Prometheus Pushgateway lets the short-lived batch job push its metrics before exiting, since Prometheus's pull model cannot scrape a process that only exists for 30 seconds every 24 hours. The Pushgateway holds those metrics until Prometheus scrapes it, satisfying the ephemeral-job constraint.

It is the deadline for the scrape response.

Errors counts failed requests, satisfying the Golden Signals requirement to track request failures. Unlike latency, which measures duration, errors quantify unsuccessful outcomes, whether explicit (HTTP 500s), implicit (malformed responses), or policy-based rejections. Google's SRE guidance names errors alongside latency, traffic, and saturation as the four signals, so this option belongs in the correct set.

A counter is a cumulative metric that only increases (or resets to zero on restart), and total HTTP requests processed fits this exactly. It monotonically accumulates, so rate() can compute requests per second over time.

Alerting rules contain PromQL expressions evaluated against the time series database; when the expression returns results for the specified duration, the alert fires. This satisfies the requirement that rules are defined using PromQL rather than a separate query language.

'Too many active series' indicates cardinality growth, so identifying which label names contribute the most series pinpoints the offending metric before any dropping or relabelling. This diagnostic step precedes remediation such as label dropping or metric relabelling.

Exporters run alongside systems that natively expose no Prometheus metrics, translating their proprietary telemetry into the Prometheus text exposition format on an HTTP endpoint. Prometheus then scrapes that endpoint like any other target, bridging the format gap without altering the monitored application.

A short-lived batch job may exit before Prometheus's next scrape interval, so its metrics endpoint disappears and the samples are never collected. This directly satisfies the stem's constraint: the job finishes in seconds, far quicker than typical polling, requiring a push gateway or similar mechanism instead.

Alertmanager is a distinct Prometheus architecture component: it receives firing alerts from the Prometheus server, then deduplicates, groups, silences and routes them to receivers such as email or PagerDuty. This matches the stem's request for a primary component.

Targets expose metrics passively, so Prometheus discovers and scrapes them without any target-side configuration naming the server. This satisfies the stem's service-discovery constraint: targets remain unaware of Prometheus's location, unlike push models where each target must know the gateway endpoint.

Relabeling rewrites label sets during service discovery, so a drop action on high-variance labels removes them before ingestion. This directly lowers series cardinality, satisfying the stem's constraint of reducing the label combinations Prometheus must store and index.

Errors counts failed requests, whether explicit failures, wrong content or policy rejections. It is a Golden Signal because it directly exposes reliability degradation, letting SRE teams alert on failure rates rather than waiting for user reports.

Latency without CPU correlation points to resource contention outside the processor: storage throughput, IOPS limits, or network bandwidth and packet loss. Examining disk I/O and network saturation metrics identifies whether the bottleneck sits in I/O waits or transport, which CPU graphs cannot reveal.

A Gauge records an instantaneous value that can rise or fall over time, such as memory usage or queue depth, unlike counters that only increase. This matches the stem's requirement to track values that fluctuate up and down.

Prometheus pulls metrics from targets at controlled intervals.

Pushgateway accepts pushed metrics without verifying that the source service is still running, so Prometheus scrapes stale values indefinitely. This directly satisfies the stem's constraint: long-running services lose Prometheus's liveness detection, since the target's up metric reflects the gateway, not the actual service instance.

Observability infers internal system state purely from emitted outputs such as logs, metrics and traces, without inspecting internals directly. This lets operators answer novel questions about behaviour the system was never explicitly instrumented to report.

The Prometheus server discovers targets through service discovery, then scrapes each instance and marks it down when unreachable. This suits ephemeral, auto-scaling microservices because target health and liveness are managed centrally without instances needing to know the server's address.

Requests per second measures demand volume hitting the web service, making it the most direct indicator of the Traffic golden signal. It reveals load changes and saturation trends that latency or error-rate metrics alone would not expose for a request-driven service.

Traffic measures demand on the system, so requests per second directly quantifies the volume of incoming work. Latency, errors and saturation describe other golden signals, but only request rate satisfies the Traffic SLO requirement in the stem.

When a target disappears, Prometheus writes a stale marker into the TSDB, causing queries to stop returning that series' last sample immediately after the lookback delta. This prevents graphs from displaying flat-lined or misleading data once the target is genuinely down.

Grafana queries Prometheus as a data source and renders its time series as dashboards, graphs and alerts. Prometheus itself offers only a basic expression browser, so pairing it with Grafana provides the visualisation layer the scenario requires for exploring collected metrics.

Metrics are numeric samples recording state at a point in time, aggregated and cheap to store. Logs are timestamped records of discrete events with full context. This axis — sampled state versus discrete event — is the fundamental distinction between the two telemetry types.

Errors is the golden signal tracking failed requests, and HTTP 404 responses count as errors for a specific endpoint. Monitoring error rate per endpoint reveals whether clients are requesting nonexistent resources, satisfying the detection requirement.

Latency is a duration measured repeatedly over time, so time-series metrics capture request durations as timestamped samples, enabling percentile and histogram analysis. This satisfies the stem's requirement, unlike logs, which record discrete events without native aggregation.

Client-side quantiles are computed within the instrumented application before export, so the Summary metric type satisfies the stem's requirement for locally calculated quantiles rather than server-side aggregation. This distinguishes it from histogram-based types, where quantiles are derived later from bucketed data in the backend.

In the pull model Prometheus actively initiates each scrape over HTTP against configured targets, rather than passively receiving pushed data. This satisfies the stem's requirement by naming the direction of initiation, the defining axis separating pull from push architectures.

Aggregating raw metrics into broader categories directly reduces cardinality by collapsing many distinct label combinations into fewer series. For example, grouping individual HTTP status codes into 2xx, 4xx and 5xx classes cuts the number of unique time series Prometheus must track, satisfying the stem's requirement for a standard cardinality-reduction technique.

histogram_quantile() calculates a quantile from histogram buckets, interpolating within the bucket containing the requested rank. Applied to a histogram's le-labelled bucket counters with rate(), it returns the P99 latency estimate, which no counter or summary function provides directly.

CPU usage percentage is a numeric measurement sampled over time, which is exactly what Prometheus stores as a time series. It satisfies the stem's requirement for metric data, unlike logs or traces, because its value is quantifiable and aggregatable.

Prometheus Server executes PromQL queries directly against its time-series database, retrieving and aggregating metric samples on demand. This satisfies the stem's requirement precisely: PromQL is Prometheus's native query language, evaluated by the server's query engine rather than by exporters, Alertmanager, or client libraries.

Every distinct label combination creates a separate time series, so high cardinality multiplies the series Prometheus must track. Each series consumes memory in the head block and index, driving up RAM usage on the server.

Emitting a counter metric per 5xx error lets Prometheus apply rate() over the series, so alerting rules fire on error frequency rather than raw log volume. This satisfies the requirement to trigger on the rate of errors, which log-based alerting cannot express directly.

Logs capture discrete, timestamped events with full contextual detail — error messages, stack traces, request identifiers and variable values — that aggregated metrics cannot retain. Metrics reveal that a failure occurred; logs explain why, satisfying the need to diagnose specific incidents rather than merely detect anomalies.

Traces capture the full causal path of a single request as it propagates across microservices, preserving parent-child span relationships and per-hop timings. High-cardinality metrics aggregate values and cannot reconstruct that request-scoped journey, so traces uniquely satisfy the need for end-to-end context when debugging one slow request.

Email addresses are effectively unique per user, so each distinct value spawns its own time series. That unbounded label-value growth multiplies active series and index size, which is precisely the high-cardinality condition the stem asks about.

Saturation quantifies how full a resource is, typically expressed as queued work awaiting service, such as requests in a queue or threads waiting. It signals impending degradation before latency or errors appear, matching the Four Golden Signals definition the stem requests.

Each distinct label combination creates a separate time series held in memory. With constant traffic but rising cardinality, new series accumulate faster than stale ones are garbage-collected, so memory grows linearly. This directly explains the symptom described in the stem.

Metrics are numeric, aggregated and cheap to store, making them suited to dashboards and trend analysis over time. Logs capture individual discrete events with rich context, better for debugging specific incidents. This aggregate-versus-event axis is the defining difference.

A unique transaction ID label creates a new time series for every transaction, so cardinality grows without bound as traffic increases. This directly satisfies the stem's high-cardinality cause, since Prometheus indexes each distinct label combination separately in its TSDB.

Alerting on causes (CPU, disk) fires on conditions users may never feel. Symptom-based alerts target observable service degradation, such as elevated error rates or latency, so pages reflect actual user impact and reduce noise from transient internal fluctuations.

Counters reset to zero on restart, so raw deltas go negative. PromQL's rate() detects the reset and treats the drop as a wrap-around, extrapolating the increase across the interval rather than reporting a spurious negative slope, which would otherwise distort the per-second average.

Grafana supplies the visualisation layer Prometheus lacks natively, rendering its time-series data into configurable panels, graphs and dashboards. This satisfies the stem's requirement for a dashboarding feature, since Prometheus itself offers only basic expression-browser graphing rather than persistent, shareable, customisable dashboards.

Static configuration files let Prometheus scrape targets listed explicitly in prometheus.yml, without any external registry. This satisfies the scenario's need for a file-based service discovery mechanism, one of the standard target sources alongside Consul and Kubernetes API discovery.

`increase()` extrapolates the counter's growth across the 5-minute range vector, automatically handling counter resets and scaling to the window boundaries. This satisfies the stem's requirement for the rise in `http_requests_total` over exactly 5 minutes, unlike `delta()`, which ignores resets and suits gauges rather than counters.

Node Exporter runs on Linux hosts and exposes hardware and kernel metrics such as CPU, memory, disk and network statistics in Prometheus format. It is one of the most widely deployed official exporters, making it a common exporter type.

Each unique user ID creates a separate time series, so memory grows with user count rather than staying bounded. Label values must have low cardinality; unbounded values like user IDs explode the index and memory footprint, which is exactly the spike observed.

Labelling a counter by 'user_id' creates one time series per distinct user, so cardinality scales with your user base. Prometheus holds every active series in memory, and each unique label combination multiplies storage and index overhead, exhausting RAM and degrading queries. This directly satisfies the stem's operational risk: unbounded cardinality from a high-churn identifier.

Retaining logs gives responders the granular, timestamped detail needed to reconstruct an incident's sequence and root cause. This satisfies the requirement for recommended observability practise by ensuring sufficient telemetry depth exists before an incident occurs, enabling precise analysis instead of relying on aggregated metrics alone.

Prometheus service discovery queries platform APIs to automatically detect scrape targets as containers and instances appear or disappear, so configuration stays accurate without manual edits. This satisfies the stem's dynamic-environment requirement, where static target lists become stale immediately after scaling events.

Traces record the full path of a single request as it crosses service boundaries, capturing per-span timing, parent-child relationships and errors. This satisfies the stem's distinction from metrics, which are aggregated numeric measurements over time rather than individual request lifecycles.

Metrics are numeric time-series suited to aggregation and rate calculations, so request rate per second is computed cheaply and stored at low cardinality. Logs would require parsing each entry to derive the same count, making metrics the efficient choice for this high-volume, continuously changing measurement.

Alertmanager receives alerts pushed from Prometheus and handles deduplication, grouping, silencing and routing to receivers such as email or Slack. It satisfies the stem's routing requirement, sitting downstream of Prometheus rather than performing the metric evaluation itself.

Prometheus TSDB maintains an inverted index mapping label pairs to posting lists of series IDs, enabling rapid label-based lookups without scanning every series. This satisfies the requirement for fast searching across high-cardinality metrics, as queries resolve matching series directly from the index before reading chunks.