Monitoring Privacy And Security¶
The optional Swarm Hosts monitoring stack keeps detailed metric history on the machine that produced it. Normal agent resource reports and operational events also provide the service with bounded diagnostic data.
Data Locality¶
Detailed historical metrics from the local monitoring stack stay on the Swarm Host. Its gateway sends chart data to an authorized browser session. The control plane stores monitor-session metadata, connection signaling, low-rate health summaries, and alert summaries, without storing the stack's chart payloads.
Separately, normal agent reports send host and server CPU and memory samples to the control plane. The service stores a bounded history of those readings for resource summaries and the customer API. Server status, sanitized logs, backup records, and operational events also reach the control plane; local monitoring does not mean that all diagnostic data stays on your machine.
Access Control¶
Monitor sessions are short-lived and scoped to a Swarm Host, an optional Swarm Server, and an allowed set of metrics. The service checks account access before issuing a session. Sharing rules still apply; a server-monitoring session also requires access to its host. Do not share session credentials or copied connection details.
Network Exposure¶
You should not expose the local collectors or metrics database to the public internet. In normal operation, browsers use the monitor gateway, and the gateway validates the session before serving metric queries.
Do not port-forward VictoriaMetrics, cAdvisor, node-exporter, or Docker metrics collector ports. The monitor gateway is the browser-facing entry point.
Metric Labels¶
Metric labels must stay low-cardinality and avoid personal or secret values. Custom game exporters must not use these as labels:
- player IDs
- IP addresses
- session IDs
- usernames
- email addresses
- request IDs
- tokens
Keeping labels stable protects privacy and prevents high-cardinality metrics from overwhelming the local metrics store.
Operational Error Events¶
Swarm Hosts may send bounded operational events to the control plane so the service can detect deployment failures, unhealthy agents, and web UI errors. These events contain severity, event type, software release, a safe summary, and opaque resource or request identifiers where needed for troubleshooting.
Operational events do not include arbitrary game logs, browser page contents, form or request bodies, cookies, authorization headers, player/chat content, email addresses, or raw IP addresses. Sensitive values are redacted before an event is accepted, and centrally stored events have a limited retention window.