Cloud Native Architecture practice questions

Distributed tracing addresses a question metrics and logs cannot answer on their own: which service in a chain caused the slowdown for one particular request?

A trace is composed of spans, each representing the work done by one service for that request, linked together so the full request path and its timing can be reconstructed.

1. A request enters the system and is assigned a unique trace identifier.
2. Each service the request passes through records a span describing its portion of the work.
3. The spans are collected and assembled into a single trace showing the full path and timing.

Exam tip: Traces are the pillar that follows one request across service boundaries.

Prometheus's defining architectural choice is a pull model: it actively scrapes targets rather than waiting for them to push data.

On a configured interval, the Prometheus server issues an HTTP request to each target's metrics endpoint (conventionally /metrics), parses the response, and stores the values with a timestamp.

1. A target application or exporter exposes current metric values on an HTTP endpoint.
2. Prometheus is configured with that target and a scrape interval.
3. Prometheus repeatedly requests the endpoint and stores each scraped sample as a labeled time series.

Exam tip: Prometheus pulls metrics via scheduled HTTP scrapes; it does not wait for targets to push data to it.

PromQL is the functional query language built specifically for Prometheus's labeled time series data model.

PromQL lets you select a metric by name and labels, apply functions like rate() or sum(), and aggregate across dimensions, which is exactly the shape of data Prometheus stores.

1. Prometheus stores each scraped sample as a labeled time series.
2. A user writes a PromQL expression naming the metric and any label filters.
3. Prometheus evaluates the expression, returning a value, vector, or graph of matching time series.

Exam tip: PromQL is Prometheus's native query language for its time series data.

The CNCF landscape sorts hosted projects into three maturity levels: sandbox, incubating, and graduated.

Graduated is reserved for projects that have demonstrated broad adoption, a healthy governance process, and production-grade stability. Prometheus, monitoring's de facto standard in Kubernetes environments, holds this status.

1. A project is donated to the CNCF and enters the sandbox stage.
2. As adoption and governance mature, it advances to incubating.
3. Once it demonstrates sustained, widespread production use, it graduates.

Exam tip: Prometheus holds CNCF graduated status, the highest maturity tier.

Not every system natively speaks Prometheus's metrics format, so the ecosystem provides exporters as a translation layer.

An exporter queries the third-party system using its own native protocol, then re-exposes the resulting values on an HTTP endpoint in the format Prometheus expects to scrape.

1. The third-party system exposes metrics in its own native format or protocol.
2. An exporter is deployed to query that system and convert its metrics.
3. The exporter serves the converted metrics on an HTTP endpoint that Prometheus scrapes like any other target.

Exam tip: Exporters adapt systems that do not natively support Prometheus so their metrics can still be scraped.

Prometheus and Alertmanager have a deliberate separation of concerns: Prometheus decides when a condition is met, Alertmanager decides what to do about it.

Alertmanager sits downstream of Prometheus, receiving fired alerts and applying deduplication, grouping of related alerts, silencing rules, and routing to the appropriate receiver.

1. Prometheus continuously evaluates configured alerting rules against scraped metrics.
2. When a rule's condition is met, Prometheus fires an alert and sends it to Alertmanager.
3. Alertmanager deduplicates and groups related alerts, then routes them to the configured notification channel.

Exam tip: Alertmanager, not Prometheus itself, handles deduplication, grouping, and routing of alerts.