How to monitor Docker containers without Prometheus or Grafana

Prometheus and Grafana is the de facto standard for Docker container monitoring in 2025. It's powerful, flexible, and free. It's also a full-time job to set up and maintain correctly. This post is for the team that Googled "docker container monitoring" and landed on a Prometheus tutorial, then spent three hours configuring exporters before giving up and wondering if there's a simpler way.

There is. Let's walk through the real complexity cost of Prometheus+Grafana for Docker container monitoring, then show what the alternatives look like when you just want to know "are my containers running and healthy?"

What Prometheus + Grafana actually requires

Prometheus is a pull-based metrics system. It scrapes metrics from endpoints you configure. Grafana is a visualization layer. Neither was designed specifically for Docker — they were designed for everything, which is both their strength and their weakness.

Here's what a proper Prometheus+Grafana Docker monitoring setup requires:

1. Prometheus itself

You need to run Prometheus somewhere. Either as a Docker container on each host, or on a dedicated monitoring server that scrapes all your hosts.

# docker-compose.yml
services:
  prometheus:
    image: prom/prometheus:latest
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus_data:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.retention.time=30d'

volumes:
  prometheus_data:

Then you need a prometheus.yml that tells Prometheus where to find your metrics:

# prometheus.yml
global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: 'cadvisor'
    static_configs:
      - targets: ['cadvisor:8080']

  - job_name: 'node-exporter'
    static_configs:
      - targets: ['node-exporter:9100']

2. cAdvisor for container metrics

Prometheus doesn't talk to Docker directly. You need cAdvisor, a Google project that exposes container metrics in Prometheus format:

  cadvisor:
    image: gcr.io/cadvisor/cadvisor:latest
    ports:
      - "8080:8080"
    volumes:
      - /:/rootfs:ro
      - /var/run:/var/run:ro
      - /sys:/sys:ro
      - /var/lib/docker/:/var/lib/docker:ro
      - /dev/disk/:/dev/disk:ro
    privileged: true
    devices:
      - /dev/kmsg

cAdvisor needs privileged access and mounts several host paths. It works, but it's another container to maintain, another thing that can break.

3. Node Exporter for host metrics

If you also want CPU, memory, and disk metrics for the host (not just containers), you need Node Exporter:

  node-exporter:
    image: prom/node-exporter:latest
    ports:
      - "9100:9100"
    volumes:
      - /proc:/host/proc:ro
      - /sys:/host/sys:ro
      - /:/rootfs:ro
    command:
      - '--path.procfs=/host/proc'
      - '--path.sysfs=/host/sys'

4. Grafana for visualization

Prometheus has no built-in dashboards. You need Grafana:

  grafana:
    image: grafana/grafana:latest
    ports:
      - "3000:3000"
    volumes:
      - grafana_data:/var/lib/grafana
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=yourpassword

Once Grafana is running, you need to:

1. Add Prometheus as a data source
2. Import a Docker dashboard (search Grafana's dashboard catalog, import by ID)
3. Customize it for your containers
4. Configure alerts (AlertManager, separate config file, separate container)

5. Alertmanager for notifications

Prometheus alerting rules live in separate YAML files. Notifications require Alertmanager, another container:

  alertmanager:
    image: prom/alertmanager:latest
    ports:
      - "9093:9093"
    volumes:
      - ./alertmanager.yml:/etc/alertmanager/alertmanager.yml

With its own config:

# alertmanager.yml
route:
  group_by: ['alertname']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 1h
  receiver: 'slack'

receivers:
  - name: 'slack'
    slack_configs:
      - api_url: 'https://hooks.slack.com/services/YOUR/WEBHOOK/URL'
        channel: '#alerts'

And alert rules go back in Prometheus config:

# alert_rules.yml
groups:
  - name: docker
    rules:
      - alert: ContainerDown
        expr: absent(container_last_seen{name=~".+"})
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Container {{ $labels.name }} is down"

The total complexity count

Let's count what you're running and maintaining:

And that's before you tackle:

• Multi-host monitoring — you need Prometheus federation or a central Prometheus scraping all hosts (requires network access between servers)
• Storage — Prometheus's local storage is not replicated; if it crashes, you lose metrics history
• Updates — five containers to keep updated and tested together
• Security — each container exposes ports, needs firewall rules
• Grafana itself crashes more than you'd think

This is not a criticism of Prometheus. It's excellent software built for serious infrastructure. But "serious infrastructure" comes with serious maintenance overhead.

The time cost nobody talks about

The setup above takes most developers 2-4 hours the first time. That's if nothing goes wrong. Then:

• Dashboard tuning: Getting a Grafana dashboard to actually show what you want (right containers, right time ranges, right alerts) takes another few hours
• Alert tuning: Alertmanager has a learning curve. Getting alerts to fire when they should and not fire when they shouldn't takes iteration
• Multi-host expansion: Adding your second server means configuring Prometheus federation or a remote_write target. More config, more potential failure points
• Ongoing maintenance: Monthly Prometheus/Grafana updates, version compatibility checks, fixing broken dashboard panels after a major update

Conservative estimate for a team of one: 8-12 hours to get Prometheus+Grafana correctly configured and tuned for a 3-5 host Docker environment.

The Kernus alternative

Here's the entire Kernus setup for the same environment:

# Install and start (runs as a background daemon)
curl -fsSL https://kernus.app/install | sh
kernus token YOUR_TOKEN --host company-backend
kernus agent start

Windows: Use WSL or Git Bash for this one-liner, or use PowerShell (see Windows install).

That's it. No config files. No additional containers. No dashboard setup. Every container running on that host is automatically discovered and monitored.

What you get out of the box:

• Container status — running, stopped, restarting, paused
• CPU and memory — with historical charts
• Restart count — and alerts when it exceeds a threshold
• OOM kill detection — automatic, no configuration
• Exit code classification — 137 (OOM), 143 (SIGTERM), 1 (app crash)
• Network I/O — bytes in/out per container
• Alerts — Slack, Discord, Telegram, Email, Webhook, SMS — configured in the UI, not YAML
• 7-day or 30-day retention — depending on plan, stored in the cloud

For a second host:

# On server 2 — generates a new token in the Kernus UI
kernus token DIFFERENT_TOKEN --host company-backend-2
kernus agent start

Both hosts appear in the same dashboard immediately.

Setup time comparison

When Prometheus is still the right choice

We're not going to pretend Kernus is always the better answer. Prometheus+Grafana wins when:

• You're running Kubernetes — the Prometheus Operator for k8s is mature and excellent. Kube-state-metrics, custom resource dashboards, HPA visibility. This is genuinely Prometheus's home turf.
• You need custom metrics from your application — if you're already instrumenting your code with Prometheus client libraries to expose business metrics (request rates, queue depths, error rates), having everything in one system is compelling.
• You have a dedicated platform team — if you have 2+ engineers whose job is to maintain the monitoring stack, the flexibility of Prometheus+Grafana is worth the complexity.
• You need long-term storage — Prometheus is ephemeral by default, but pairing it with Thanos or Cortex gives you years of metric retention. Useful for compliance or capacity planning at scale.
• You're on an air-gapped network — no internet connectivity, everything must be self-hosted. Kernus requires internet access.

For everyone else — small teams, Docker-centric infrastructure, 1-20 hosts, and an engineering team where everyone has 12 other responsibilities — the operational overhead of Prometheus+Grafana is hard to justify.

The honest tradeoff

Prometheus+Grafana is more powerful and more flexible. Kernus is faster to set up and easier to operate. These aren't competing claims — they're just different points on the simplicity-vs-flexibility curve.

If you're not sure which one you need, a reasonable heuristic: if you can't dedicate 4+ hours to setting it up and 1-2 hours/month to maintaining it, don't use Prometheus. Use something that works immediately and gets out of your way.

You can always migrate to Prometheus later when you have the team to justify it. Starting with Prometheus when you're running 3 containers on a $20 VPS is engineering theater, not engineering.

---

Want to see how Kernus compares to Datadog? Read our Datadog pricing breakdown. If you're evaluating Grafana Cloud specifically, check out our Kernus vs Grafana Cloud comparison.

Start monitoring in 2 minutes →