Metrics telemetry — collector setup & topology charts

Cloud Control charts real time-series metrics for each resource on the Network topology map — click a compute instance (or any resource) and its CPU, memory, network and latency appear in the inspector, the way CloudWatch's *Explore related* view works. The data comes from a collector you install in your own cloud/app/server; Cloud Control polls it read-only over HTTPS and stores a bounded window of samples.

1. Install a collector

Cloud Control reads any Prometheus-compatible GET /api/v1/query_range endpoint. The simplest setup is node_exporter on each instance scraped by Prometheus (or a Vector agent with a prometheus_exporter sink). The one requirement is that each series carries the resource's native id under a label Cloud Control recognises:

• AWS — instance_id (relabel from __meta_ec2_instance_id).
• GCP — instance_id or instance_name (relabel from __meta_gce_instance_id).
• Azure — vm_id or resource_id (relabel from __meta_azure_machine_id).
• Alibaba — instanceId (set on the ECS scrape target).

The exact relabel snippet per cloud is shown inline on the resource's Metrics endpoint panel (Network map → select the resource → Metrics endpoint). Because the endpoint is dedicated to that one resource, no per-series id label is required by default; if you point a shared endpoint at several resources and it labels series by id, set an optional identity-label filter there.

2. Connect the endpoint — on the resource

The endpoint is configured per resource, because the collector agent is installed on that specific server/app — its endpoint belongs to the resource, not the cloud account. Open the Network map, click the resource, and in the inspector open Metrics endpoint. Paste your Prometheus base URL (must be https://; http:// is allowed only on loopback for local dev) and, if it requires one, a bearer token. The token is encrypted at rest (AES-256-GCM under CC_DATA_KEY) and is never returned to the browser — the form shows only whether one is set. Only cloud-account managers can set it.

3. See the charts

A scheduled poll runs every 15 minutes (and once immediately when you connect); for each configured resource it queries the profile's PromQL and stores the points. Open the Network map and click the resource — its charts render in the inspector, right above the endpoint panel. Until a poll has stored samples, the inspector shows an honest empty state (with the install hint) rather than fabricated data.

Limitations (read these)

• App-side storage, not a native TSDB. Samples are kept in the platform database with a bounded retention window (24h by default, METRIC_RETENTION_HOURS). There are no rollups/downsampling and reads are exact-window only. A real Prometheus / VictoriaMetrics is a drop-in behind the same storage seam.
• Poll cadence. Resolution is the cron cadence (15 min) plus the connect-kick — not sub-minute. A shorter cadence or a push path is future work.
• Dedicated endpoint. Because the endpoint belongs to one resource, every series it returns is attributed to that resource — no id label is required. For a shared endpoint, set the optional identity-label filter so only that resource's series are charted.
• You run the exporter. Cloud Control renders the recommended install snippet but does not provision node_exporter / Prometheus / Vector for you.
• Honest empty on failure. An unreachable, unauthorized or misconfigured endpoint yields no samples — never a fabricated series and never a failed sync.