Limiting Portainer-related alerts to actionable events without notification noise
0 reputation · 04 Mar 2022, 13:11 UTC
We manage several Docker hosts through Portainer CE and want alerting on container and endpoint health. Since CE has no built-in notification engine, we plan to use external tooling (Prometheus/Alertmanager or a lightweight health-check script polling the Portainer API) against the same endpoints Portainer already inventories.
The unresolved decision is severity mapping. Alerting on every container start/stop would flood us given frequent deployments, but we are unsure which state changes are genuinely actionable: non-zero exits, restart loops, sustained unhealthy status, agent/endpoint down, and host resource thresholds all seem candidates, yet the line between self-healing noise and page-worthy events is unclear.
Constraints
- Community Edition, so no Portainer-native notifications assumed
- API polling should not add meaningful load to the Portainer instance
- Deduplication needed so one flapping container does not page repeatedly
Which container and endpoint events do you treat as page-worthy versus log-only in a Portainer-managed fleet? Is polling the Portainer API for endpoint/container status a reasonable low-volume health check, or is scraping Docker events/cAdvisor metrics strictly better? What deduplication or grouping strategy keeps restart-loop alerts to a single notification?