How To Set Up Docker Swarm Monitoring for Real Cluster Visibility

Docker Swarm is simple to set up, but gets more complex as the cluster grows. A service can appear healthy from the manager node while tasks are restarting on worker nodes, memory is tightening on one host, or a failed node remains part of the routing path. Without clear cluster-wide monitoring, however, those issues remain hidden until they become user-facing failures.

This guide gives you a clear path to reliable Docker Swarm monitoring. It covers the metrics you should monitor, how Docker Swarm logging and monitoring fit together, which Docker Swarm monitoring tools you should consider, and where Dokploy can reduce your setup and maintenance burden.

If you're new to monitoring Docker Swarm, the short version is this: a single host's metrics tell you almost nothing about the cluster as a whole.

Why Docker Swarm monitoring is different from single-host monitoring

Docker Swarm spreads replicas across multiple nodes, so a local view is never enough.

You're not only monitoring Docker containers on one server. You're also tracking the health of a swarm cluster, where services deployed on different worker nodes and manager nodes can fail, restart, or reschedule independently.

Essentially, a node-level problem can stay invisible unless your monitoring stack collects data across the full cluster.

That distributed design also affects how you handle failures. A failing node may still receive traffic while its tasks restart or fail to reach the desired replica count, so comprehensive visibility has to cover both host-level and service-level signals at once.

Key metrics to monitor in a Docker Swarm cluster

A swarm problem is usually a cluster problem, so what are the crucial metrics to monitor?

At the infrastructure level, track the following per node and per container:

• CPU and memory usage.
• Disk usage.
• Network throughput.

At the service level, focus on:

• Desired replicas versus running replicas.
• Restart rates.
• Task scheduling failures.

Those metrics tell you whether or not resource usage is healthy and if the swarm is actually keeping services available. It's the same ground covered by general server monitoring and container monitoring, but tracked across every node in the cluster instead of just the one.

If you're running Dokploy across multiple servers, its horizontal scaling feature already runs on Docker Swarm mode under the hood.

Self-hosted Dokploy ships basic resource monitoring for servers and containers by default, covering CPU and memory at a glance, with a default metrics port of 4500 protected by a token.

The fuller, configurable version of that monitoring dashboard, with custom refresh rates, longer retention windows, alert thresholds, and notification callbacks, is available on Dokploy Cloud and Enterprise.

For deeper node-level detail, its Swarm API also exposes per-node and per-container stats programmatically. Either way, built-in monitoring is a solid first layer. But it isn't a substitute for the alerting rules, long-term time series storage, and dashboard depth the dedicated tools below provide.

Docker Swarm logging and monitoring

The previous section covered metrics, but metrics alone don't explain failures.

When it comes to managing both Docker Swarm logging and monitoring together, the job is to connect cluster symptoms to root causes.

• Monitored metrics tell you that CPU is pinned, memory is rising, or a service is below its desired replica count.
• Logs tell you whether the real issue is an application crash, an image pull error, a bad configuration, or a network timeout.

In a swarm, logs are emitted per container and per node, so root-cause analysis depends on central aggregation rather than hopping between hosts. Docker supports multiple logging drivers for that routing layer, including json-file, syslog, gelf, and fluentd.

The default is json-file, but without rotation, this can consume significant disk space. For cluster logging, the usual pattern is to configure a remote driver such as syslog, gelf, or fluentd in daemon.json or at container start, then forward service logs to a central collector. That setup gives you one place to analyze events across multiple services and nodes.

Docker Swarm monitoring tools

After you've scoped out metrics and logs, the next step is choosing the right tools. The options to choose from below range from fully open source and self-hosted to the kind of managed server monitoring software you don't have to maintain, so you can pick based on how much of the stack you actually want to run yourself.

Prometheus and Grafana

Best for: Teams that want full control over metrics collection and dashboards and are comfortable self-hosting the stack.

The most common Docker Swarm monitoring open source stack combines Prometheus for metrics collection, cAdvisor for container-level metrics, Node Exporter for host-level metrics, and Grafana for dashboards and alerting.

Prometheus scrapes metrics endpoints over HTTP and stores time series data locally, while cAdvisor and Node Exporter run as global services, meaning one replica lands on every node automatically as the cluster grows.

A minimal Swarm pattern for the exporters looks like this:

services:
  cadvisor:
    image: gcr.io/cadvisor/cadvisor:v0.49.1
    deploy:
      mode: global
    volumes:
      - /:/rootfs:ro
      - /var/run:/var/run:ro
      - /sys:/sys:ro
      - /var/lib/docker/:/var/lib/docker:ro
    privileged: true
    ports:
      - "8080:8080"
  node-exporter:
    image: prom/node-exporter:v1.8.0
    deploy:
      mode: global
    pid: host
    volumes:
      - /proc:/host/proc:ro
      - /sys:/host/sys:ro
      - /:/rootfs:ro
    command:
      - '--path.procfs=/host/proc'
      - '--path.sysfs=/host/sys'
      - '--path.rootfs=/rootfs'
    ports:
      - "9100:9100"

Prometheus is then configured with scrape targets for those exporters, either hardcoded or through its dockerswarm_sd_configs service discovery, which auto-discovers nodes, services, and tasks directly from the Docker socket.

For teams that want a quicker starting point, Swarmprom packages Prometheus, Grafana, and related components as a deployable stack, reducing the manual work required to get exporters, dashboards, and alert routing running in one cluster-aware setup.

Once your dashboards are in place, Grafana's alerting can notify you when CPU stays high, memory pressure crosses a threshold, or running replicas drop below the expected count, using native contact points for destinations like Slack and PagerDuty.

Features

• Native Docker Swarm service discovery via dockerswarm_sd_configs, covering node, service, and task roles.
• A built-in time series database with its own query language (PromQL) for building alerting rules.
• Grafana dashboards you fully control, down to individual panels and thresholds.
• Runs entirely on infrastructure you already own, with no data leaving your cluster.
• Swarmprom as a pre-packaged shortcut if you don't want to wire up every component by hand.

Portainer

Best for: Teams that want a visual interface to manage a swarm cluster and deploy a monitoring stack without writing every Compose file by hand.

Portainer provides you with a web UI for Docker Swarm that sits on top of the same manager node you'd otherwise have to manage from the CLI. Instead of running docker service ls and docker node ls across an SSH session, you get a dashboard showing every node, stack, and service in the cluster.

For monitoring specifically, Portainer includes an app template that deploys a Prometheus and Grafana stack onto your swarm cluster in a few clicks, tagging the manager node so the deployment lands in the right place.

Starting like this is much faster than writing the Compose file yourself, though you'll be running and maintaining the same underlying Prometheus and Grafana instances either way.

Features

• One-click app templates for deploying a monitoring stack onto an existing swarm cluster.
• A visual view of nodes, stacks, and services across the whole cluster.
• Role-based access control for teams managing the same cluster.

Netdata

Best for: Teams that want real-time, low-overhead monitoring with close to zero configuration.

Netdata runs as a per-node agent that auto-discovers running containers and services the moment you install it, with no scrape configs or dashboards to build first.

For Docker Swarm specifically, it pulls Swarm-specific metrics through the Docker Engine's built-in Prometheus exporter, including which node holds the manager leader role and how many nodes and tasks exist per lifecycle state.

That auto-discovery speeds up the path to visibility on a new cluster, and its per-second granularity is closer to true real-time monitoring than a 15-second Prometheus scrape interval, catching short spikes a slower interval can miss.

Netdata isn't as deep as some other competitors, however: dashboards and alerting are less customizable than what you'd build yourself in Grafana, and its per-node agent model means that if you want to view true cluster-wide state you still need to aggregate across nodes rather than querying one central store.

Features

• Zero-configuration auto-discovery of containers and services on install.
• Per-second metric granularity.
• Docker Swarm-specific metrics, including manager leader state and node and task counts.
• A free tier with unlimited metrics retention on a single node.

Datadog

Best for: Teams that want a fully managed, commercial observability platform and don't want to run or maintain the monitoring stack themselves.

Datadog takes a different approach to the other monitoring tools on this list: you install its agent on every host, and it automatically collects Docker and Docker Swarm metadata, tagging containers and services so you can filter and group by them later.

Swarm services can carry Datadog's own autodiscovery labels, so new services picked up by the agent get monitored using the right integration without you touching a config file per service.

The trade-off is cost and control. You're paying per host, and your metrics live on Datadog's infrastructure rather than your own. In exchange, however, you get out-of-the-box dashboards, log management, and alerting that would otherwise take real setup time to replicate with a self-hosted stack.

Features

• Autodiscovery via integration labels on Swarm services, no per-service config file required.
• Out-of-the-box dashboards spanning host, container, and service-level metrics.
• Combined metrics, logs, and alerting in one platform.

Monitoring Docker Swarm with Dokploy

If building and maintaining that monitoring stack feels like a second project, Dokploy is the natural next option.

Dokploy offers a built-in monitoring section with real-time server and container metrics, 20-second default refresh intervals, retention settings managed by an automated cron job, include and exclude service filtering, threshold-based notifications, token-protected metrics requests, and port 4500 as the default metrics port.

For those who want the lower-level cluster detail, Dokploy’s Swarm API documents endpoints for swarm.getNodes, swarm.getNodeInfo, and swarm.getNodeApps with x-api-key authentication.

Dokploy's built-in monitoring dashboard is available on both self-hosted and Cloud deployments. The main distinction is that threshold-based alert notifications are currently a Cloud-only feature—self-hosted instances have full access to the metrics dashboard and configuration options, but alert routing to notification platforms requires the Cloud plan.

Conclusion

Docker Swarm monitoring only works when you treat the cluster as the unit of truth. You need cluster-wide metrics for CPU, memory, disk, network, replicas, restarts, and scheduling failures – plus centralized logging so the same dashboard that shows a problem can also lead you to why it happened.

Which tool fits best comes down to how much of that stack you want to own versus hand off, from a fully self-hosted Prometheus and Grafana setup to a managed platform like Datadog.

If you're already running services across multiple servers with Dokploy, you're likely running Docker Swarm under the hood already, with basic resource monitoring included as a starting point. Sign up for Dokploy to see how it handles multi-server deployments alongside the tools covered here.

Docker Swarm monitoring FAQs

What is Docker Swarm monitoring?

Docker Swarm monitoring is the practice of collecting and analyzing cluster-wide metrics, service health data, and logs across a Docker Swarm cluster so you can detect node failures, restart storms, replica drift, and resource pressure before they become outages.

What are the best Docker Swarm monitoring tools?

Prometheus, cAdvisor, Node Exporter, and Grafana make up the most common open source stack, with Swarmprom as a faster way to deploy it. Portainer adds a visual layer on top of that same stack. Netdata trades some customization for near-zero setup, and Datadog is a strong option if you'd rather not run any of it yourself.

How does Docker Swarm logging and monitoring work together?

Logging routes container output from each node into a central collector using Docker logging drivers such as json-file, syslog, gelf, or fluentd. Metrics show that something broke; centralized logs help you work out why.

Is there an open source Docker Swarm monitoring option?

Yes. Prometheus, cAdvisor, Node Exporter, and Grafana are all free and open source, and Swarmprom packages them together as a ready-to-deploy stack. Netdata's free tier also covers unlimited metrics retention on a single node.

How do I make sure monitoring covers every node in my cluster, not just one?

Deploy your exporters, such as Node Exporter and cAdvisor, with deploy: mode: global so a replica runs on every node automatically, including new ones as the cluster grows. Then confirm your Prometheus service discovery role and relabel configs aren't accidentally filtering out targets from specific nodes.