CCNA Instrumentation And Exporters Questions

node_exporter's default listen address is :9100, so it serves metrics on TCP port 9100 unless overridden with --web.listen-address. This default port is what Prometheus scrape configs for node targets conventionally reference, satisfying the question's requirement for a true statement.

The Prometheus server performs the scraping: it pulls metrics from configured targets at set intervals via HTTP. For a custom exporter, the exporter merely exposes metrics in Prometheus format on an endpoint; the server initiates collection. This satisfies the stem's requirement by identifying the active puller rather than the passive endpoint.

Client libraries accept a label dictionary (map of label names to values) passed at metric creation or observation time, which attaches those key-value pairs to the sample. This is the mechanism for adding dimensions such as method or status to a custom metric.

The http_2xx module probes the endpoint and marks success only when the returned HTTP status code falls in the 2xx range, directly satisfying the requirement to check the status code. Other modules such as tcp_connect or icmp test reachability, not HTTP response codes.

Each metric sample occupies its own line, with the metric name, optional labels and value separated by whitespace, and lines terminated by a line feed. This line-oriented structure is what parsers rely on, satisfying the requirement for a true statement about the exposition format.

Client-side quantiles are computed per instance, so a Summary metric cannot be aggregated across instances; Prometheus cannot merge pre-computed quantiles. This satisfies the stem's constraint by preventing cross-instance aggregation, unlike Histograms, which expose bucket counters that aggregate correctly server-side.

Client libraries expose application metrics on a `/metrics` endpoint, letting Prometheus pull counter, gauge, histogram and summary values during each scrape. This satisfies the stem's instrumentation requirement: the library is the component embedded in your code that records and publishes measurements before the Prometheus server retrieves them.

Histogram buckets are cumulative: every bucket whose upper bound is greater than or equal to the observed value increments. With 0.7 seconds, the 1 and 5 buckets increment, while 0.1 and 0.5 do not, since 0.7 exceeds their bounds.

A Counter is a monotonically increasing value that only goes up, resetting to zero on restart, which suits a cumulative request tally. Tracking requests received requires this monotonic behaviour, and rate() or increase() can then derive per-second rates.

Official client libraries expose metrics directly from application code in the Prometheus exposition format, so a scrape endpoint is served without a separate exporter. This satisfies the stem's requirement for a standard handling method, since instrumentation at source is the canonical approach for custom application metrics.

Using `start_http_server()` from the Prometheus Python client spins up a background HTTP endpoint that exposes metrics in the Prometheus text format, satisfying the requirement to expose custom exporter metrics without a separate web framework. It is the idiomatic, minimal-code approach for Python exporters.

Prometheus text exposition format lets the custom exporter present metrics that Prometheus can scrape natively, satisfying the interoperability requirement. Each metric needs HELP and TYPE annotations plus a consistent naming convention, so the collector parses values without transformation. This directly addresses the design consideration of choosing an output format compatible with the monitoring platform consuming the data.

node_exporter is the standard Prometheus exporter for Linux hosts, exposing CPU, memory, disk, filesystem and network metrics from /proc and /sys. It directly satisfies the requirement to track CPU usage alongside other hardware and OS metrics.

A gauge represents a value that can rise or fall, making it the correct type for memory usage, which fluctuates as allocations and frees occur. Counters would be unsuitable because they only increase and cannot represent a current level.

Pushgateway lets short-lived batch jobs push their metrics to an intermediary that Prometheus then scrapes, since the job terminates before a normal pull scrape can occur. This satisfies the stem's constraint of a job finishing before scraping.

blackbox_exporter probes endpoints over HTTP, HTTPS, TCP and ICMP from wherever its instance runs, exposing results as Prometheus metrics. Deploying multiple instances across regions satisfies the stem's geographic requirement, letting you alert on probe_success and latency per location.

Descriptive, clear metric names satisfy the stem's requirement for defining metric names by making each series self-documenting, so engineers can identify what a measurement represents without external context. This reduces ambiguity during querying and alerting, directly supporting maintainability across dashboards and Prometheus-style label sets.

GaugeVec wraps a Gauge with a label dimension, exposing one child metric per label-value combination via WithLabelValues. This satisfies the stem's requirement to distinguish the two types: a plain Gauge holds a single unlabelled value, whereas GaugeVec permits per-label tracking, such as by endpoint or status code.

The '_sum' metric accumulates the total of all observed values, complementing '_count' and '_bucket', which track observation counts and distribution boundaries. It satisfies the requirement to store the summed observations rather than counts or buckets.

Histogram buckets store cumulative counts per bucket, not individual observations, so the 99th percentile cannot be read directly. Merging histograms across instances requires summing bucket counts and interpolating within the target bucket, which introduces approximation error and cannot recover the true percentile.

The _count suffix exposes the number of observations aggregated into that summary or histogram series, independent of the sum or bucket values. It lets you compute averages and rates by dividing other suffixes by this sample total.

The `--no-collector.textfile` flag disables the textfile collector at startup, satisfying the requirement to switch off a specific collector. node_exporter accepts `--no-collector.<name>` for any registered collector, so the textfile collector is excluded from the metrics endpoint without affecting others.

Prometheus scrapes each target within a configured scrape_timeout; if the exporter's response exceeds that window, the scrape is cancelled and marked as failed. Raising the timeout, or speeding up the exporter's collection, resolves the timeout errors.

A NaN gauge value signals an undefined or missing measurement, not a zero reading. The metric exists but its current state cannot be computed, so the gauge renders no valid numeric value. This matches the undefined gauge state the stem describes.

Histogram buckets are cumulative: each _bucket series counts all observations less than or equal to its upper bound, so values increase monotonically across buckets. This cumulative layout is what enables histogram_quantile() to interpolate quantiles from the bucket counts.

`prometheus.MustRegister()` adds a collector to the default registry, which the `/metrics` endpoint exposes automatically. It panics on duplicate registration, surfacing programming errors immediately rather than silently dropping the metric. This satisfies the stem's requirement for the standard registration mechanism in the Go client library.

Short-lived batch jobs finish before Prometheus can scrape them, so their final metrics would be lost. Pushing those metrics to the Pushgateway preserves them for the Prometheus server to scrape afterwards, satisfying the ephemeral-job constraint.

The Blackbox exporter performs active probing from outside the target, and its probe modules support HTTP, TCP, DNS, ICMP and gRPC checks. Supporting HTTP, TCP and DNS satisfies the multi-protocol probing capability the question asks about.

The module block selects the probe type—HTTP, TCP, ICMP or DNS—and its parameters such as preferred IP protocol, timeouts and valid status codes. It therefore determines the protocol-specific behaviour the blackbox_exporter applies when testing the web endpoint.

The instance label records the specific target endpoint scraped, typically host:port, distinguishing multiple replicas or jobs sharing the same metric names. This satisfies the need to identify which individual target produced a given sample during querying and alerting.

In a Prometheus histogram, the `le` label defines each bucket's inclusive upper bound, so a bucket labelled `le="0.5"` counts every observation less than or equal to 0.5 seconds. This satisfies the stem's requirement by naming the comparison operator that determines which observations fall into each cumulative bucket.

A gauge represents a value that can rise or fall arbitrarily over time, such as the current count of active connections. Counters only increase monotonically, so they cannot accurately reflect a connection total that decreases when sessions close.

Labels form part of the metric's unique time series identity. Embedding unbounded dynamic values such as request IDs, user IDs or timestamps creates a new series per value, exploding cardinality and overwhelming the time-series database with memory and storage pressure.

Blackbox_exporter performs active probing of endpoints over HTTP, HTTPS, DNS, TCP and ICMP, returning metrics such as response time, status code and TLS certificate expiry. This satisfies the stem's requirement for the primary function, since it monitors externally observable behaviour rather than internal host metrics.

prometheus.MustRegister() registers a collector with the default registry and panics on error, which is the idiomatic call in Go client libraries. It ensures the metric is exposed on the /metrics endpoint without requiring explicit error handling.

Scraping requires the Prometheus server to reach the target's metrics endpoint over the network. Firewalls, DNS failures, routing problems or unreachable hosts prevent the HTTP request completing, so the scrape fails outright. This satisfies the stem's requirement for a common scraping failure cause.

Prometheus scrapes targets on a fixed interval, so metrics must be exposed consistently rather than only when they change. Continuously exposing the current value lets each scrape capture the state, satisfying the periodic-exposure requirement without gaps.

Gauges represent a single numerical value that can arbitrarily increase or decrease, such as temperature or current memory usage. Prometheus exposes this as a valid metric type, satisfying the question's requirement for three valid types alongside counter and histogram.

A gauge records a value that can rise or fall arbitrarily at any moment, such as the current count of active sessions. Counters only increase or reset, histograms and summaries track distributions of observations, so neither represents an instantaneous fluctuating total.

Tracking memory consumption is a core node_exporter use case because it exposes host-level metrics such as node_memory_MemAvailable_bytes and node_memory_MemTotal_bytes from /proc/meminfo. This satisfies the scenario's requirement for operating system memory visibility, which application-level instrumentation cannot provide.

Underscore-prefixed metric names are reserved for internal use by the monitoring system, so user-defined metrics cannot claim them. This satisfies the stem's constraint on naming impact: such metrics are hidden from standard queries and dashboards, and Prometheus-style tooling treats them as non-public, preventing collisions with system-generated series.

Each unique label value combination creates a distinct time series. Unbounded or high-churn label names multiply series combinatorially, overwhelming Prometheus memory and storage. Fixing label names constrains that growth, directly preventing the cardinality explosion the stem asks about.

A gauge represents a value that can rise or fall arbitrarily, such as current memory usage, which fluctuates as a process allocates and releases memory. Counters and histograms cannot capture this instantaneous, bidirectional measurement correctly.

High-cardinality labels, such as unique user IDs or timestamps, create unbounded time series that inflate storage costs and slow PromQL queries. The stem asks what to avoid, and this directly violates the cardinality constraint that keeps custom metrics performant and cost-effective in Prometheus.

A Counter only increases (or resets to zero on restart), making it the natural fit for a cumulative total of requests received. PromQL rate() and increase() then derive request rates from this monotonically increasing series.

Pushgateway stores pushed metrics in a keyed grouping identified by job and instance labels. Pushing a metric with an identical name and label set replaces the previously stored value for that key rather than appending a new series.

A custom HTTP exporter pushes metrics or traces directly to a collector endpoint over HTTP, satisfying the requirement for a valid instrumentation approach. Unlike agents or auto-instrumentation libraries, it gives explicit control over payload format and destination, letting applications emit telemetry without depending on vendor-specific SDKs.

Node_exporter listens on TCP port 9100 by default, exposing Prometheus-format metrics at the /metrics endpoint. This satisfies the stem's requirement for the standard default port without any command-line override, so scrapes configured against port 9100 succeed immediately after installation.

PromQL parses metric names as identifiers, so characters such as hyphens or spaces would break query syntax. Restricting names to alphanumerics, underscores and colons keeps them valid tokens, letting the expression engine resolve selectors without quoting or escaping.

Prometheus scrapes metrics endpoints expecting the Prometheus Text Format, a line-based exposition syntax of metric name, optional labels and a sample value. A custom exporter emitting JSON, CSV or XML cannot be parsed by the scrape pipeline, so the text format satisfies the stem's scraping requirement.

If node_exporter is not running or bound to a different interface, Prometheus scrapes will fail silently, so confirming the listener and port reachability isolates the fault before investigating scrape configuration or firewall rules. This directly tests the stem's missing-metrics symptom at its source.