Task 4.1: Observability

• APer-service CPU and memory metrics averaged over five minutes

  Incorrect

  Aggregated metrics show trends per service; they cannot follow one request through the chain.

• BNode CPU pressure graphs for each worker node

  Incorrect

  Node graphs show machine load, not where one request spent its time.

• CDistributed traces that link the timed spans of one request

  Correct

  Traces capture how a request moves across components and link the latency and timing of each operation, so the slow hop stands out.

• DKubernetes events for the services' Pods

  Incorrect

  Events report object changes such as scheduling or restarts, not request timings.

Metrics, logs and traces answer different questions. For "where did this request spend its time", traces are the signal.

• AIt scrapes each component's /metrics endpoint at a regular interval

  Correct

  Kubernetes components emit metrics in Prometheus format from /metrics, and the pipeline periodically scrapes and stores the samples.

• BThe components push their metrics to Prometheus over OTLP as each value changes

  Incorrect

  OTLP is how Kubernetes can export trace spans. Component metrics are pulled from /metrics endpoints.

• CPrometheus reads the metric values that the components store in etcd

  Incorrect

  etcd holds API objects, not time series; metrics are served by each component.

• DThe kubelet writes metrics into each container's log stream for collection

  Incorrect

  Container logs carry application output; metrics have their own endpoints.

Prometheus works by pulling: it scrapes HTTP /metrics endpoints on a schedule and stores the samples in its time series database.

• AApplications write their logs to stdout and stderr

  Correct

  The container runtime captures the stdout and stderr streams and the kubelet integration stores them as log files on the node.

• BA node-level agent such as Fluent Bit ships the node's log files to the store

  Correct

  A node-level logging agent tails the node's log files and forwards entries to a central log store.

• CEngineers run kubectl logs and archive the output as needed

  Incorrect

  kubectl logs reads what is still on the node; when the Pod is deleted or the logs rotate, that history is gone.

• DApplications write logs to an emptyDir volume so they survive restarts

  Incorrect

  emptyDir is deleted with the Pod, so the logs disappear exactly when they are needed.

• EThe API server is configured to store container logs in etcd

  Incorrect

  etcd stores API objects; container logs are not kept there.

Cluster-level logging needs storage independent of nodes and Pods: applications log to stdout and stderr, and a per-node agent forwards the files to a backend.

• ARaise the kubelet's container log rotation size

  Incorrect

  Rotation applies to logs the runtime already captured, not to files inside a container.

• BAdd a sidecar that streams the file to its own stdout

  Correct

  A streaming sidecar reads logs from a file, socket or journal and prints them to its own output streams.

• CPut the log directory on an emptyDir that kubectl logs reads

  Incorrect

  kubectl logs returns the log file the kubelet keeps for the container's stdout and stderr streams; files in a volume are not part of it.

• DSet terminationMessagePath to the application's log file

  Incorrect

  That path is for a short message about termination, not ongoing logs.

Sidecar containers adapt applications that cannot log to stdout and stderr.

• AHow well the system can grow to do more of its work

  Incorrect

  That is scalability, the glossary's term for how well a system can grow.

• BHow well the system recovers from failures without human help

  Incorrect

  That is self-healing: a control loop compares actual with desired state and repairs certain failures without human intervention.

• CHow well the system keeps working as its components fail

  Incorrect

  That is reliability, which the glossary describes as how well a system responds to failures.

• DHow well the system's outputs explain its internal state

  Correct

  Observability is the degree to which a system can generate actionable insights, so that users can understand its state from its external outputs and take corrective action.

Observability, scalability, self-healing and reliability are separate properties in the CNCF glossary. An observable system produces signals such as logs, metrics and traces that let operators understand what is going on inside it and act on it.

• AFrom the kubelet on each node

  Correct

  Metrics Server is a cluster add-on that pulls resource metrics from each kubelet, which exposes them through its /metrics/resource endpoint.

• BFrom etcd, where each Pod's usage is recorded

  Incorrect

  The pipeline does not pass through etcd: usage is gathered on each node by cAdvisor in the kubelet, and Metrics Server pulls it from the kubelets.

• CFrom the container runtime on each node, over the CRI

  Incorrect

  Runtime and cgroup figures reach the kubelet, through cAdvisor or CRI container metrics; Metrics Server talks to the kubelets, not to the runtimes.

• DFrom its own agent Pods, one per node, reading cgroups

  Incorrect

  Metrics Server queries each node's kubelet over HTTP. Reading cgroups is the job of cAdvisor, which is built into the kubelet.

In the resource metrics pipeline, cAdvisor inside the kubelet collects container usage, the kubelet exposes it, and Metrics Server pulls it from every kubelet and serves it through the Metrics API.

• AThe webhook backend, through --audit-webhook-config-file

  Correct

  The webhook backend sends audit events to a remote web API; its config file, in kubeconfig format, gives the service's address and credentials.

• BThe log backend, through --audit-log-path

  Incorrect

  The log backend writes audit events into the file system at that path, which is what the team wants to move away from.

• CAn audit policy whose rules use the level RequestResponse

  Incorrect

  The policy decides which events are recorded and how much of each request and response they include, not where the events are sent.

• DThe --audit-policy-file flag, set to the service's URL

  Incorrect

  That flag takes the path of a local policy file with the rules; it does not name a destination for the events.

kube-apiserver has two built-in audit backends: the log backend writes events to files, and the webhook backend sends them to an external HTTP API. The audit policy, passed with --audit-policy-file, decides what is recorded for either backend.