Skip to content

Observability Concepts: PCA practice questions

Observability is the ability to understand a system from the outside by asking questions about it, without knowing its inner workings in advance. That requires telemetry, the data a system emits about its behaviour, and the OpenTelemetry observability primer describes three main signals. A log is a timestamped message emitted by a service or component.

By Ibrahim Yesilay · Published · Updated

Independent community practice, not affiliated with or endorsed by CNCF or The Linux Foundation.

What Observability Concepts covers in PCA

Observability is the ability to understand a system from the outside by asking questions about it, without knowing its inner workings in advance. That requires telemetry, the data a system emits about its behaviour, and the OpenTelemetry observability primer describes three main signals. A log is a timestamped message emitted by a service or component. A metric is an aggregation over a period of time of numeric data about infrastructure or an application, such as a request count or the current memory use. A distributed trace records the path a single request takes through the services it touches, and it is made of spans, each span being one unit of work or operation with a start, an end and attributes attached as metadata.

The signals answer different questions. Metrics summarize many events in a few numbers, which makes them the natural input for dashboards and alerts. Logs keep the detail of individual events. Traces show where the time went inside one slow request that crossed several services, which an aggregated latency metric cannot tell you. Prometheus is a metrics system: its FAQ is blunt that it is not meant for logs and points to tools such as Grafana Loki or OpenSearch instead.

Prometheus collects metrics by pulling. The server scrapes targets over HTTP, and the targets come from static configuration or from service discovery, which lets it follow systems where instances come and go, such as Kubernetes, without editing the file for every change. The FAQ gives the practical advantages of pulling: you can more easily and reliably tell when a target is down, you can start extra monitoring instances as needed, and you can open a target's metrics page in a browser to check its health. For short-lived batch jobs that may finish before they can be scraped, the Pushgateway acts as an intermediary that the job pushes to and Prometheus then scrapes.

Reliability vocabulary rounds the topic out. Reliability asks whether the service is doing what users expect. A Service Level Indicator is a measurement of a service's behaviour, for example how many requests are answered within a latency target. A Service Level Objective is the target set for an indicator, and the primer calls it the means by which reliability is communicated to the organization and to other teams.

Finally, Prometheus is explicit about where it does not fit: when you need complete accuracy, such as for per-request billing, the collected data may not be detailed or complete enough, and a separate system should handle that job while Prometheus covers monitoring.

Key points

  • Logs are timestamped messages, metrics are numeric aggregations over time, traces follow one request and consist of spans.
  • Prometheus pulls metrics over HTTP from targets found through static configuration or service discovery.
  • Short-lived jobs push to the Pushgateway, which Prometheus then scrapes.
  • An SLI measures service behaviour; an SLO is the target for that indicator.
  • Prometheus is not designed for logs or for 100% accurate data such as per-request billing.

Three sample questions

72 PCA questions on Observability Concepts, 18 with explanations. How practice works

Question 1

In monitoring terminology, what is a metric?
  1. A.A free-form text line emitted by an application during execution
  2. B.A request traced as it flows through several services
  3. C.A numeric measurement of a system or application captured over time
  4. D.A discrete record stating that a specific thing happened at a point in time

Correct answer: C

Metrics are numeric measurements sampled over time, such as request counts, latencies, or memory usage. Free-form text records are logs, request flows across services are traces, and discrete 'something happened' records are events.

Question 2

Which characteristic best distinguishes logs from metrics?
  1. A.Logs are discrete, timestamped, often textual records of events, while metrics are numeric values sampled over time
  2. B.Logs are always numeric aggregates while metrics are always textual
  3. C.Logs cannot contain timestamps whereas metrics always do
  4. D.Logs are stored only in memory while metrics are always written to disk

Correct answer: A

Logs are typically discrete event records that are often textual and timestamped, whereas metrics are numeric measurements sampled at regular intervals. Both can carry timestamps, and storage location is an implementation detail, not a defining difference.

Question 3

What is an 'event' in observability terms?
  1. A.A continuously increasing counter exposed by an exporter
  2. B.A pre-aggregated rollup of metric data over a time window
  3. C.A sampled gauge value representing current resource usage
  4. D.A record indicating that something notable occurred at a specific point in time

Correct answer: D

An event captures the fact that something discrete happened at a moment in time (for example, a deployment or a login). Counters, gauges, and aggregated rollups are forms of metric data, not events.

Practice this topic

Focus mode keeps every question on Observability Concepts until you leave it. 10 free guest answers, then a free account; no credit card.

Or open PCA practice across all topics.

Sources

The explanation above was checked against these official documents.