nerdexam
Cisco

300-910 · Question #34

A DevOps engineer is supporting a containerized application with multiple components running across the Kubernetes cluster. Metrics from the containers (CPU and memory) and application (requests per s

The correct answer is A. Grafana has lost connectivity to Prometheus, which causes graphs to display only the cached data.. The question describes a scenario where application issues (transaction timeouts) are reported, but monitoring graphs appear normal, and asks for a reason why the problem wouldn't be visible in the metrics.

Monitoring and Logging

Question

A DevOps engineer is supporting a containerized application with multiple components running across the Kubernetes cluster. Metrics from the containers (CPU and memory) and application (requests per second and heap size) are being collected by Prometheus and displayed with Grafana. Users report transaction timeout problems with the application, but the metric graphs all look within normal levels. Which type of failure would prevent the engineer from seeing the problem using the captured metrics?

Exhibit

300-910 question #34 exhibit

Options

  • AGrafana has lost connectivity to Prometheus, which causes graphs to display only the cached data.
  • BCPU and memory metrics from Kubernetes nodes are not accurate due to the way that containers share resources.
  • CSome containers are crashing regularly and being restarted automatically by Kubernetes.
  • DThe metricbeat agent has crashed and is no longer sending new data to Prometheus, so the metrics are not updating.

How the community answered

(21 responses)
  • A
    81% (17)
  • B
    5% (1)
  • C
    5% (1)
  • D
    10% (2)

Why each option

The question describes a scenario where application issues (transaction timeouts) are reported, but monitoring graphs appear normal, and asks for a reason why the problem wouldn't be visible in the metrics.

AGrafana has lost connectivity to Prometheus, which causes graphs to display only the cached data.Correct

If Grafana loses connectivity to Prometheus, it might continue to display the last known good data or cached data, making the graphs appear normal even though new, problematic metrics are not being pulled. This gives a false sense of security while the underlying issue persists.

BCPU and memory metrics from Kubernetes nodes are not accurate due to the way that containers share resources.

While resource sharing can complicate metric interpretation, CPU and memory metrics from Kubernetes nodes are generally accurate for resource usage and would typically reflect problems if they were the cause of timeouts.

CSome containers are crashing regularly and being restarted automatically by Kubernetes.

If containers are crashing and restarting regularly, this would likely be reflected in metrics such as restart counts, pod status, and potentially dips in request rates, making the problem visible.

DThe metricbeat agent has crashed and is no longer sending new data to Prometheus, so the metrics are not updating.

If the metricbeat agent (or Prometheus scrapers, assuming metricbeat is used to feed Prometheus) crashed, Prometheus would not receive new data, leading to stale or absent graphs, which would immediately indicate a monitoring problem, not give a false "normal" reading.

Concept tested: Monitoring system failures

Source: https://prometheus.io/docs/prometheus/latest/getting_started/

Topics

#Kubernetes#Prometheus#Grafana#Monitoring Troubleshooting

Community Discussion

No community discussion yet for this question.

Sign up to join the discussion
Full 300-910 Practice