Skip to content

ServiceRadar

Open navigation

Operations

Edge agent runtime

One edge binary per site. Outbound mTLS to the cloud gateway, collectors and plugins next to the network, and a control stream for config and commands.

Deploy serviceradar-agent at the site edge: outbound mTLS to agent-gateway, sandboxed Wasm plugins, native add-ons, local anomaly detection, and signed fleet updates—without opening inbound management ports.

Outbound mTLS, not a hole in the firewall

serviceradar-agent connects out to agent-gateway over mTLS gRPC. Identity comes from the certificate. Agents do not join the core data plane, do not talk to the database, and do not need inbound ports opened for the control plane to reach them.

  • mTLS gRPC to agent-gateway with certificate-derived identity
  • Hello, config fetch, status push, and bidirectional control stream
  • Config and commands pushed without polling a public management interface
  • Works through segmented and hard-to-reach sites with outbound reach only

Agent-gateway is the cloud front door

Edge agents talk to agent-gateway, not to every internal service. The gateway enrolls agents, delivers versioned config, carries command traffic, and forwards ingestion into the platform. That boundary keeps edge hosts out of the cluster and keeps secrets and storage on the platform side.

  • Single gateway service surface for edge gRPC APIs
  • Versioned GetConfig with not-modified when nothing changed
  • Unary and streaming status for small and large result payloads
  • Control stream for commands, acks, progress, and config updates

Wasm plugins in a real sandbox

Custom checks and integrations run as WebAssembly plugins in an embedded wazero runtime. Plugins do not get raw filesystem or socket access. Network and host calls go through a capability-based ABI that operators approve, with per-plugin memory, CPU, and connection limits.

  • Sandboxed Wasm execution—no arbitrary native code on the edge by default
  • Capability-based host ABI with operator-approved manifests
  • Resource budgets for memory, CPU time, and open connections
  • Portable wasm32 artifacts across agent platforms

Native add-ons when you need more than Wasm

Not every edge capability belongs in a sandbox. Native add-ons cover privileged or heavy runtimes—endpoint inventory scanners, optional local exposure scanning, RDP helpers, netprobe, and similar packages—reviewed, approved, and assigned separately from base agent releases.

  • Base agent stays lean; add-ons install only where approved
  • Separate catalogs for agent runtime releases and native add-on packages
  • Assignments and profiles target cohorts instead of one-off edits
  • Keep privileged helpers out of the default fleet package

Anomaly detection at the edge

Metric streams can be evaluated on the agent so you surface sustained spikes and drift without shipping every noisy sample for central evaluation. Findings fold into episodes and enter the normal event and alert workflow, with fleet defaults from Settings and optional per-profile overrides.

  • Edge evaluation of metric series for spikes and drift
  • Bounded episodes instead of one event per noisy sample
  • Seasonal baselines where daily or weekly patterns matter
  • Settings and profiles project safe config to the fleet

Easy to deploy, easy to update

Onboarding is install the package, create an agent package in the UI, paste the enroll command. Fleet updates use signed releases, cohort rollouts, and automatic rollback when an updated runtime does not come back healthy—so you can move versions without a maintenance weekend of hand installs.

  • RPM/DEB install from releases, then UI enroll with a short-lived token
  • Outbound-only path to agent-gateway after enrollment
  • Signed agent releases with digest and signature verification
  • Canary and broad rollouts with automatic rollback on health failure

FAQs

Does the agent need inbound ports from the cloud?

No. The agent connects outbound over mTLS to agent-gateway. Config and commands arrive on that connection.

How are plugins kept safe?

Wasm plugins run in a sandbox with a capability-based host ABI. They cannot touch the host filesystem or network directly; only approved, mediated host calls are allowed, under resource limits.

What are native add-ons for?

Capabilities that need privileges or runtimes outside the Wasm sandbox—such as certain scanners or optional helpers—ship as separate native packages, reviewed and assigned apart from the base agent.

Can we roll out agent updates safely?

Yes. Publish a signed release, roll it to a cohort, and rely on health-based automatic rollback if the new runtime fails to recover.

Where are the technical docs?

Edge model, onboarding, plugins, anomaly tuning, and release management live in the Edge Model docs .