Monitor the management server

The management server reports its own health so you can answer “is it loaded, is it saturated, and who is connected?” without external tooling — and, when you want it, expose the same numbers to your existing monitoring.

Server load & saturation on the Health page

Open Operate → Health. Between the server card and the collector fleet you’ll find Server load & saturation:

• Saturation tiles — CPU, memory (RSS), heap, goroutines, GC pause, open file descriptors, and store size. A tile turns amber or red when it crosses a threshold, with a short hint.
• Connections — established connections split by type (agents, OpAMP sessions, remotecfg pollers, live-feed clients) with a total headline.
• Workload sparklines — API requests, ingest, config pushes, active captures, and dry-runs over the last 3 hours (toggle to 24 hours).

Note

History is kept in memory and resets when the server restarts — the uptime tile tells you when that last happened. For history that survives restarts, scrape the server into your own Prometheus (below).

Scrape the server with Prometheus

The server can expose its metrics in Prometheus text format. It is off by default — turn it on and the endpoint appears behind the normal API authentication.

1. Enable the endpoint in the server configuration:

   metrics:
     enabled: true

2. Create a service-account token with permission to read health, and use it as a bearer token for the scrape.

3. Point Prometheus at /api/v1/metrics:

   scrape_configs:
     - job_name: linkmesh-server
       scheme: https
       metrics_path: /api/v1/metrics
       authorization:
         type: Bearer
         credentials: <your-service-account-token>
       static_configs:
         - targets: ['app.linkmesh.io']

Every series is prefixed linkmesh_server_ — for example linkmesh_server_connections_agents, linkmesh_server_process_rss_bytes, and linkmesh_server_dryrun_executions_total. A linkmesh_server_build_info gauge carries the running version.

Dogfooding: monitor the server with its own fleet

Because the endpoint is plain Prometheus text, one of your own managed collectors can scrape it with a prometheus receiver and forward the result to wherever your fleet already ships telemetry — the control plane observed by the fleet it manages. Add a Prometheus source to a collector and target the server’s /api/v1/metrics path with the same bearer token.

Caution

Self-monitoring has one honest limit: if the server is down, its own metrics are down too. Scraping it from outside — your central Prometheus, or a collector on a different host — is exactly the mitigation, so an outage is visible from somewhere that isn’t the thing that’s out.

See also

• Set up alerting — get notified when a collector’s throughput, errors, or queue depth cross a threshold, rather than watching for it.
• Self-telemetry — the per-collector metrics behind the fleet view (distinct from the server’s own /api/v1/metrics).