Skip to content
intermediate Phase 14 · Docker Monitoring & Logging

Prometheus for Docker

Export container metrics to Prometheus for monitoring.

1h
0 problems
Topic Progress 0%

Exposing Metrics

Exposing Metrics

Prometheus pulls, so something must serve a /metrics text endpoint. Applications instrument with a client library:

import { Registry, Counter } from "prom-client";
const registry = new Registry();
registry.registerMetric(new Counter({
  name: "http_requests_total",
  help: "HTTP requests",
  labelNames: ["method", "route", "status"],
}));

Infrastructure metrics come from exporters: cAdvisor reports per-container CPU, memory, and network from cgroups; node_exporter covers the host. Run both as containers with their ports published, and the same scrape job picks them up as it does your app.

Scrape Configuration

Scrape Configuration

Containers change IPs, so scrape published ports or file-based targets:

scrape_configs:
  - job_name: app
    static_configs:
      - targets: ["host.docker.internal:3000"]
  - job_name: cadvisor
    static_configs:
      - targets: ["cadvisor:8080"]
  - job_name: docker-labels
    file_sd_configs:
      - files: ["/etc/prometheus/targets/*.json"]

Run Prometheus on the same Compose network as exporters (cadvisor:8080 resolves by service name) and mount its config read-only. file_sd lets a script or discovery step rewrite target JSON without touching prometheus.yml, which keeps reloads declarative. Verify with the /targets page: each target must be UP, not merely listed.

Pitfalls and Interview Angles

Pitfalls and Interview Angles

Ephemeral IPs. Scraping container-ip:port breaks the moment the container is recreated; scrape stable names (service DNS, published ports) or regenerate file_sd files on change.

Cardinality. Label values like request IDs or user IDs multiply time series and can exhaust memory; label with bounded dimensions (route, status) and log the rest.

Pull surprises. If a container has no published port and Prometheus is not on its network, the scrape silently fails — network reachability is part of the metric design.

Interview: describe the pull model, name the three exporter layers (app, cAdvisor, node_exporter), and explain how you would keep targets correct across container recreates.

Quiz

1. How does Prometheus collect metrics?

Question 1 options

2. Why scrape service names instead of container IPs?

Question 2 options

3. What do cAdvisor and node_exporter add beyond app metrics?

Question 3 options

Flashcards

Question

Pull model

Answer

Prometheus scrapes HTTP /metrics endpoints on an interval; apps only expose.

Question

cAdvisor

Answer

Container metrics exporter: CPU, memory, network, filesystem from cgroups.

Question

node_exporter

Answer

Host-level exporter for CPU, memory, disks, and network.

Question

file_sd_configs

Answer

Targets loaded from JSON files a script can rewrite without editing prometheus.yml.

Question

Label cardinality

Answer

Unbounded label values (user IDs) multiply series and blow up memory — keep labels bounded.

Revision Notes

Key Takeaways

  • 1. Pull design makes network reachability part of monitoring
  • 2. Three layers: app counters, cAdvisor containers, node_exporter host
  • 3. Stable target addresses and bounded labels keep it running

Interview Tips

  • • Walk the scrape path and say which network each job traverses
  • • Give an example of a cardinality explosion and the fix

Cheat Sheet

app /metrics + cAdvisor + node_exporter; scrape by service DNS or file_sd, never raw container IP; bounded labels; check /targets are UP.

Continue Learning