Prometheus for Docker monitoring - Time & Space Complexity
When using Prometheus to monitor Docker containers, it's important to understand how the time to collect metrics grows as the number of containers increases.
We want to know how the monitoring process scales when more containers are added.
Analyze the time complexity of this Prometheus scrape configuration for Docker containers.
scrape_configs:
- job_name: 'docker'
static_configs:
- targets: ['container1:9100', 'container2:9100', 'container3:9100']
metrics_path: '/metrics'
scrape_interval: 15s
# Prometheus scrapes each container's metrics endpoint
# to collect monitoring data regularly.
This config tells Prometheus to collect metrics from each Docker container's metrics endpoint every 15 seconds.
Look at what repeats during the monitoring process.
- Primary operation: Prometheus sends HTTP requests to each container's metrics endpoint.
- How many times: Once per container every scrape interval (e.g., every 15 seconds).
As the number of containers increases, the number of HTTP requests Prometheus makes grows.
| Input Size (n containers) | Approx. Operations (HTTP requests) |
|---|---|
| 10 | 10 requests per scrape |
| 100 | 100 requests per scrape |
| 1000 | 1000 requests per scrape |
Pattern observation: The number of requests grows directly with the number of containers.
Time Complexity: O(n)
This means the time to collect metrics grows linearly as you add more containers to monitor.
[X] Wrong: "Adding more containers won't affect Prometheus scraping time much because it scrapes in parallel."
[OK] Correct: Even if scraping happens in parallel, each container adds a request that consumes resources and time, so total work still grows with container count.
Understanding how monitoring scales helps you design systems that stay reliable as they grow. This skill shows you can think about real-world system behavior, not just code.
What if Prometheus used a push model instead of scraping each container? How would the time complexity change?
Practice
Solution
Step 1: Understand Prometheus purpose
Prometheus is designed to collect and store metrics data from various sources, including Docker containers.Step 2: Differentiate from other Docker tools
Prometheus does not run containers, build images, or replace Docker Engine; it focuses on monitoring.Final Answer:
To collect and store metrics from Docker containers -> Option BQuick Check:
Prometheus = Metrics collection [OK]
- Confusing Prometheus with Docker Engine
- Thinking Prometheus builds images
- Assuming Prometheus runs containers
Solution
Step 1: Identify correct cAdvisor image and port
The official cAdvisor image is hosted at gcr.io/cadvisor/cadvisor:latest and listens on port 8080.Step 2: Check port mapping and image name
docker run --name cadvisor -p 8080:8080 gcr.io/cadvisor/cadvisor:latest correctly maps port 8080:8080 and uses the official image name.Final Answer:
docker run --name cadvisor -p 8080:8080 gcr.io/cadvisor/cadvisor:latest -> Option AQuick Check:
cAdvisor image and port = docker run --name cadvisor -p 8080:8080 gcr.io/cadvisor/cadvisor:latest [OK]
- Using wrong image repository
- Mapping wrong ports
- Using outdated or incorrect image tags
scrape_configs:
- job_name: 'cadvisor'
static_configs:
- targets: ['localhost:8080']What will Prometheus do when started with this config?
Solution
Step 1: Analyze scrape_configs job_name and targets
The job 'cadvisor' targets 'localhost:8080', which is the default cAdvisor port.Step 2: Understand Prometheus scraping behavior
Prometheus will scrape metrics from the specified target, not Docker Engine API or all containers directly.Final Answer:
Scrape metrics from cAdvisor running on localhost port 8080 -> Option DQuick Check:
Prometheus scrapes targets listed = Scrape metrics from cAdvisor running on localhost port 8080 [OK]
- Confusing cAdvisor with Docker Engine API
- Assuming Prometheus scrapes containers directly
- Thinking config syntax is invalid
Solution
Step 1: Check port exposure between cAdvisor and Prometheus
If cAdvisor does not expose port 8080 or network is misconfigured, Prometheus cannot scrape metrics.Step 2: Verify other options
Wrong job_name or missing image tags usually cause errors but not silent no metrics; port 9090 is Prometheus default, not cAdvisor.Final Answer:
cAdvisor container is not exposing port 8080 to Prometheus -> Option CQuick Check:
Port exposure needed for scraping = cAdvisor container is not exposing port 8080 to Prometheus [OK]
- Ignoring port exposure issues
- Assuming job_name mismatch causes no metrics
- Confusing Prometheus and cAdvisor ports
Solution
Step 1: Understand cAdvisor scope
cAdvisor monitors containers on the host it runs on; to monitor multiple hosts, run cAdvisor on each host.Step 2: Configure Prometheus for multi-host scraping
Prometheus can scrape metrics from multiple cAdvisor instances by listing all hosts in its config.Step 3: Evaluate other options
Central cAdvisor cannot monitor other hosts; running Prometheus on each host complicates aggregation; single host setup misses other hosts.Final Answer:
Run cAdvisor on each host exposing metrics, configure Prometheus to scrape all hosts -> Option AQuick Check:
One cAdvisor per host + Prometheus scrape all = Run cAdvisor on each host exposing metrics, configure Prometheus to scrape all hosts [OK]
- Thinking one cAdvisor can monitor all hosts
- Running multiple Prometheus instances unnecessarily
- Ignoring multi-host scraping config
Ready to prove it?
Pass the test and this pattern moves unknown
