Why Prometheus for metrics collection in Kubernetes? - Purpose & Use Cases

The Big Idea

What if you could catch server problems before your users even notice?

The Scenario

Imagine you run a busy website with many servers. You want to know how fast each server responds and if any are failing. Without tools, you check logs and stats by hand on each server.

The Problem

Checking each server manually is slow and tiring. You might miss problems or get wrong info because data is scattered. It's like trying to find a needle in many haystacks without a magnet.

The Solution

Prometheus collects all your servers' performance data automatically in one place. It watches your systems constantly and lets you see clear graphs and alerts when something goes wrong.

Before vs After

✗ Before

ssh server1
cat /var/log/app.log
ssh server2
cat /var/log/app.log

✓ After

kubectl apply -f prometheus-deployment.yaml
kubectl port-forward svc/prometheus 9090:9090

What It Enables

With Prometheus, you can quickly spot issues and keep your systems healthy without endless manual checks.

Real Life Example

A company uses Prometheus to monitor their online store's servers. When response times rise, Prometheus alerts the team immediately, preventing slowdowns and lost sales.

Key Takeaways

Manual monitoring is slow and error-prone.

Prometheus automates data collection and alerting.

This helps keep systems reliable and responsive.

Practice

1. What is the main purpose of Prometheus in a Kubernetes environment?

easy

A. To deploy applications automatically

B. To collect and store metrics data for monitoring

C. To manage Kubernetes cluster nodes

D. To provide a user interface for Kubernetes

Solution

1. Step 1: Understand Prometheus role

   Prometheus is designed to collect numerical data called metrics from applications and systems.

2. Step 2: Identify its main function in Kubernetes

   In Kubernetes, Prometheus collects metrics to monitor app health and performance.

3. Final Answer:

   To collect and store metrics data for monitoring -> Option B

4. Quick Check:

   Prometheus collects metrics = A [OK]

Hint: Prometheus = metrics collection tool [OK]

Common Mistakes:

• Confusing Prometheus with deployment tools
• Thinking Prometheus manages nodes
• Assuming Prometheus is a UI tool

2. Which Kubernetes resource is used to tell Prometheus which services to monitor?

easy

A. ServiceMonitor

B. PodMonitor

C. ConfigMap

D. Ingress

Solution

1. Step 1: Identify Prometheus monitoring resources

   Prometheus uses special Kubernetes custom resources to know what to watch.

2. Step 2: Recognize ServiceMonitor's role

   ServiceMonitor tells Prometheus which Kubernetes services to scrape metrics from.

3. Final Answer:

   ServiceMonitor -> Option A

4. Quick Check:

   ServiceMonitor selects services for Prometheus [OK]

Hint: ServiceMonitor = tells Prometheus what to watch [OK]

Common Mistakes:

• Confusing PodMonitor with ServiceMonitor
• Using ConfigMap for monitoring targets
• Thinking Ingress controls Prometheus scraping

3. Given this snippet of a ServiceMonitor YAML, what is the scrape interval Prometheus will use?

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: example-monitor
spec:
  endpoints:
  - port: web
    interval: 15s
  selector:
    matchLabels:
      app: example

medium

A. 5 seconds

B. 30 seconds

C. 15 seconds

D. 1 minute

Solution

1. Step 1: Locate the interval field in YAML

   The interval is set under endpoints as 'interval: 15s'.

2. Step 2: Understand interval meaning

   This means Prometheus scrapes metrics every 15 seconds from the specified port.

3. Final Answer:

   15 seconds -> Option C

4. Quick Check:

   interval: 15s means 15 seconds [OK]

Hint: Check 'interval' value under endpoints [OK]

Common Mistakes:

• Ignoring the interval field and guessing default
• Confusing seconds with minutes
• Assuming interval is global, not per endpoint

4. You created a ServiceMonitor but Prometheus is not scraping metrics from your service. Which of these is a likely cause?

medium

A. The ServiceMonitor selector labels do not match the service labels

B. The Prometheus server is not running on the cluster

C. The service port is not exposed in the ServiceMonitor endpoints

D. All of the above

Solution

1. Step 1: Check label matching

   If ServiceMonitor selector labels don't match service labels, Prometheus won't find the service.

2. Step 2: Verify Prometheus server status and endpoint config

   Prometheus must be running and the service port must be correctly specified in endpoints to scrape metrics.

3. Final Answer:

   All of the above -> Option D

4. Quick Check:

   Any mismatch or missing config stops scraping [OK]

Hint: Check labels, server status, and endpoints all match [OK]

Common Mistakes:

• Only checking one cause and ignoring others
• Assuming Prometheus always runs by default
• Forgetting to expose correct port in ServiceMonitor

5. You want Prometheus to scrape metrics from multiple services with different scrape intervals. How should you configure this in Kubernetes?

hard

A. Create separate ServiceMonitor resources for each service with their specific intervals

B. Set a global scrape interval in Prometheus config and ignore ServiceMonitor intervals

C. Create one ServiceMonitor with multiple endpoints, each having its own interval

D. Use a ConfigMap to list all services and intervals for Prometheus

Solution

1. Step 1: Understand ServiceMonitor scope

   Each ServiceMonitor targets services with specific scrape configs; intervals are per endpoint.

2. Step 2: Manage different intervals

   To have different intervals per service, create separate ServiceMonitors with their own intervals.

3. Step 3: Why not other options?

   One ServiceMonitor with multiple endpoints cannot set different intervals per service easily; global config overrides intervals; ConfigMap does not control scraping targets.

4. Final Answer:

   Create separate ServiceMonitor resources for each service with their specific intervals -> Option A

5. Quick Check:

   Separate ServiceMonitors allow different intervals [OK]

Hint: Use separate ServiceMonitors for different intervals [OK]

Common Mistakes:

• Trying to set different intervals in one ServiceMonitor
• Ignoring ServiceMonitor intervals in favor of global config
• Using ConfigMap incorrectly for scraping targets