Repository navigation
feat: add the swarm scheduler exporter - #313
Merged
Merged
Conversation
There was a problem hiding this comment.
🟡 Changes recommended
Swarm deployment ignores the configured security_opt settings, so the promised no-new-privileges restriction needs supported enforcement or a corrected hardening claim.
1 open issue
What changed in this PR
Adds cluster-level monitoring to complement the existing node and container metrics, exposing Swarm node availability and service task counts to Prometheus.
Changes:
- Adds a production scheduler exporter and a manager-node Docker socket proxy.
- Restricts proxy access through an internal network and a read-only API allowlist.
- Adds the Prometheus scrape target and updates the generated service reference.
| File | Description |
|---|---|
src/production/swarm-scheduler-exporter/compose.yaml |
Defines the exporter deployment and health check. |
src/production/docker-socket-proxy/configurations/allowlist.env |
Defines permitted Docker API sections and blocks writes. |
src/production/docker-socket-proxy/compose.yaml |
Defines the socket proxy and internal overlay network. |
src/development/prometheus/configurations/prometheus.yaml |
Adds the exporter scrape target. |
artifacts/docs/README.md |
Documents both production services and analytics profile membership. |
Review effort: Balanced
docker stack deploy silently ignores security_opt, so the no-new-privileges restriction was never applied to either service
dargmuesli
marked this pull request as ready for review
October 22, 2026 18:27
dargstack 4.20.0 resolves dot-relative env_file entries against the declaring compose's dir, so the stack root prefix workaround comes out. The compatibility floor rises to 4.20.0, so a node running an older CLI refuses the stack until it updates.
maevsi-bot
pushed a commit
that referenced
this pull request
Oct 22, 2026
## [21.4.0](21.3.4...21.4.0) (2026-10-22) ### Features * add the swarm scheduler exporter ([#313](#313)) ([bcac72a](bcac72a))
|
🎉 This PR is included in version 21.4.0 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The metrics monitoring currently observes node and container level metrics only. This adds the cluster level view: which managers are available, and whether each service runs its desired number of tasks.
It deploys swarm-scheduler-exporter as a single replica on a manager node, where the docker daemon serves the cluster-wide service, node and event data the exporter reads. The exporter does not mount the docker socket itself: a pinned docker-socket-proxy in front of it forwards only the API sections the exporter needs, read-only, and both services run with all capabilities dropped, the exporter additionally on a read-only root filesystem, on an internal network nothing else can reach. The exporter's image ships the health check the stack relies on to replace a stuck exporter task.
The metrics monitoring gains a scrape job for the exporter. The new signals include
swarm_cluster_nodes_by_statefor manager availability,swarm_service_at_desiredandswarm_service_running_replicascompared againstswarm_service_schedulable_replicasfor per service task gaps, andswarm_exporter_healthfor the exporter itself. The proxy makes the API read-only for the exporter, not least-privilege: the enabled sections still allow reading service and task logs, which can hold secrets.