ServiceRadar is a distributed network monitoring system designed for infrastructure and services in hard-to-reach places or constrained environments. It provides real-time monitoring of internal services with cloud-based alerting to ensure you stay informed even during network or power outages.
Demo site available at https://demo.serviceradar.cloud login: demo@serviceradar.cloud password: serviceradar
- Distributed Architecture: Multi-component design (Agent, Gateway, Core) for flexible edge deployments.
- WASM Plugin System: Securely extend monitoring with custom checks in Go or Rust. Runs in a hardware-level sandbox with zero local dependencies and proxied networking.
- Topology: GPU-native topology engine capable of rendering millions of interactive nodes and edges at 60fps via [deck.gl], (https://deck.gl/), Apache Arrow for zero-copy streaming, and WASM-native logic layer.
- Custom React Dashboards: Build powerful, data-driven dashboards with the Dashboard SDK. Dashboards run inside ServiceRadar, receive SRQL-backed data frames, and can be developed locally with hot module reloading before publishing.
- Causal Engine: Real-time triage and isolation via DeepCausality (Rust). Employs hybrid filtering and roaring bitmaps to identify root causes and visually isolate an event's "blast radius" in microseconds.
- Anomaly Engine: Anomaly Engine scores numeric time series at the edge (robust median/MAD spikes plus CUSUM drift) and in core (seasonal hour-of-week baselines, episode lifecycle, severity, and capacity runway). Findings are episode-bounded—open/update/clear with cooldowns and storm shedding—so operators get durable alerts instead of noisy per-sample alarms.
- SRQL: intuitive key:value syntax for querying time-series and relational data.
- Unified Data Layer: Powered by CloudNativePG, TimescaleDB, PGVector, and Apache AGE for relational, time-series, and graph topology data.
- Monitoring: Monitor endpoints with ICMP/TCP checks, create composite service checks from multiple vantage points by deploying serviceradar-agent in edge/segmented networks.
- Observability: Native support for OTEL, GELF, Syslog, SNMP (polling/traps), BGP (BMP), and NetFlow.
- Graph Network Mapper: Discovery engine that maps interfaces and topology relationships via SNMP/LLDP/CDP.
- Notifications: Notifications turn an alert into a page through routes, escalation policies, and channels (Slack, Discord, email, webhooks, plus declarative and Wasm providers). Every attempt—including silences and withheld sends—is written to the Delivery Log, with retry, failover, and escalation kept as three separate knobs.
- Ansible Automation: Run AWX/AAP playbooks against devices in the inventory with live per-host run telemetry, projected to OCSF for the universal log viewer. AWX-sourced and git-sourced playbook catalogs coexist; cron-driven schedules ride the same launch pipeline. See docs/ansible.md.
- Security: Hardened with mTLS, RBAC, and SSO integration. Build images, WASM plugins, and add-ons are signed. SBOMs ship with every build.
ServiceRadar replaces traditional "script-and-shell" plugins with a modern WebAssembly runtime. This provides a generation leap in security and portability:
| Feature | ServiceRadar (WASM) | Traditional NMS (Nagios/Zabbix) | Enterprise (SolarWinds) |
|---|---|---|---|
| Isolation | Hardware Sandbox | None (OS Process) | None (User Session) |
| Dependencies | Zero (Static Binaries) | High (Local Libs/Python) | High (.NET/Runtimes) |
| Security | Capability-based (Proxy) | Sudo/Root access | Local Admin / WMI |
| Portability | Cross-platform WASM | Script-specific | Windows-centric |
| Auditability | Every network call logged | Invisible to Agent | Opaque |
Why WASM? Plugins are "FS-less" by default. They cannot access the host filesystem or raw sockets. Instead, they use a Network Bridge where the Agent proxies specific HTTP/TCP calls based on admin-approved allowlists.
Go: https://github.com/carverauto/serviceradar-sdk-go
Rust: https://github.com/carverauto/serviceradar-sdk-rust
ServiceRadar supports customer-owned dashboard packages that are authored in React and rendered directly inside the web UI. The Dashboard SDK gives dashboard authors a stable browser-module API for SRQL queries, Arrow-backed data frames, query state, Mapbox/deck.gl maps, popups, filters, and local development.
The published npm packages make it straightforward to create and validate a dashboard from a normal JavaScript workspace:
npm create @carverauto/create-dashboard@latest my-dashboard -- --template react-map
cd my-dashboard
npm ci
npm run devUse npm run dev for the local HMR harness, npm run validate before handing a
package to ServiceRadar, and npx serviceradar-cli dashboard publish when you
are ready to upload a signed dashboard package to a ServiceRadar instance.
Dashboard SDK documentation: developer.serviceradar.cloud/docs/v2/dashboard-sdk
Developer portal: developer.serviceradar.cloud
Get ServiceRadar running in under 5 minutes:
# Optional - set these in your .env
export SERVICERADAR_HOST=<my-vm-ip>
export GATEWAY_PUBLIC_BIND=0.0.0.0
git clone https://github.com/carverauto/serviceradar.git
cd serviceradar
docker compose pull
docker compose up nats-creds-init
docker compose up -d
# Get your admin password
docker compose logs config-updaterAccess: http://localhost (login: root@localhost)
ServiceRadar provides an official Helm chart for Kubernetes deployments, published to Harbor as an OCI artifact.
# Find the latest published chart version, then inspect its defaults
helm show chart oci://registry.carverauto.dev/serviceradar/charts/serviceradar | grep '^version'
helm show values oci://registry.carverauto.dev/serviceradar/charts/serviceradar \
--version <chart-version> > default-values.yaml
# Install or upgrade (no repository checkout needed). Put only the keys you
# change in my-values.yaml (it can start empty), not a copy of the defaults.
helm upgrade --install serviceradar oci://registry.carverauto.dev/serviceradar/charts/serviceradar \
--version <chart-version> -n serviceradar --create-namespace -f my-values.yaml
# Track mutable images (staging/dev only): pulls :latest and forces re-pull
helm upgrade --install serviceradar oci://registry.carverauto.dev/serviceradar/charts/serviceradar \
-n serviceradar --create-namespace \
--set global.imageTag="latest" \
--set global.imagePullPolicy="Always"
# Get password for 'root@localhost' user created by helm install
kubectl get secret serviceradar-secrets -n serviceradar \
-o jsonpath='{.data.admin-password}' | base64 -dNote: the chart and its images are published together and pull anonymously. If you leave global.imageTag empty (the default), every first-party image except serviceradar-cnpg (pinned by digest) uses the chart's own version, so --version alone selects matching images; if you set it, it must be v<chart-version>. Only the staging/dev example uses latest, with global.imagePullPolicy=Always to pick up new pushes on restart.
ServiceRadar publishes Cosign-signed images to Harbor. The public verification key is committed in docs/cosign.pub.
For the self-hosted keyless migration path, keep custom Sigstore trust material under docs/sigstore/README.md. The release scripts now support both legacy key-based verification and keyless verification against a custom trusted root.
Verify a released or immutable image tag with:
cosign verify \
--experimental-oci11 \
--key docs/cosign.pub \
registry.carverauto.dev/serviceradar/serviceradar-core-elx:v1.4.49For build-specific images, prefer the immutable sha-<commit> tags:
cosign verify \
--experimental-oci11 \
--key docs/cosign.pub \
registry.carverauto.dev/serviceradar/serviceradar-core-elx:sha-ac23dc0ebcbee0d6a964dc8307826bf2a063536cSuccessful verification proves the image was signed with the ServiceRadar release key and that the signature published in Harbor matches the requested image.
For self-hosted keyless verification, use the published trusted root and
certificate identity policy instead of docs/cosign.pub:
cosign verify \
--experimental-oci11 \
--trusted-root docs/sigstore/trusted-root.json \
--certificate-identity-regexp '<issuer-specific SAN regex>' \
--certificate-oidc-issuer https://issuer.example.com \
registry.carverauto.dev/serviceradar/serviceradar-core-elx:sha-ac23dc0ebcbee0d6a964dc8307826bf2a063536cDocker Compose notes:
- Set
APP_TAGin.envto pin release images (example:APP_TAG=v1.4.49). - Set
COMPOSE_FILE=docker-compose.yml:docker-compose.dev.ymlin.envto default to the dev overlay without-f.
Chart URL: oci://registry.carverauto.dev/serviceradar/charts/serviceradar
Notes:
- Chart versions are like
1.4.49; ServiceRadar image tags are likev1.4.49. - Published images pull anonymously, so no registry credentials are needed.
image.registryPullSecret(defaultregistry-carverauto-dev-cred) only matters when you pull through an authenticated mirror; set it to""to drop the reference otherwise.
For ArgoCD deployments, use registry.carverauto.dev/serviceradar/charts as the repository URL (without the oci:// prefix):
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: serviceradar
namespace: argocd
spec:
destination:
server: https://kubernetes.default.svc
namespace: serviceradar
source:
repoURL: registry.carverauto.dev/serviceradar/charts
chart: serviceradar
targetRevision: "<chart-version>"The chart version selects matching images, so the Application needs no global.imageTag. Remove any global.imageTag an existing Application still sets before changing targetRevision.
- Agent: Lightweight Go service on monitored hosts; manages WASM execution and local collection.
- Agent-Gateway: Ingestion point that receives gRPC streams from edge agents.
- Core (core-elx): Control plane (Elixir/Phoenix/Ash) for orchestration, ERTS, and job scheduling (Oban).
- Web UI (web-ng): Real-time LiveView dashboard and APIs for configuration and visualization.
- NATS: NATS JetStream message broker for bulk ingestion streams.
- Collectors: Collect bulk data (netflow, logs, SNMP, etc.).
For detailed guides on setup and security, visit: https://docs.serviceradar.cloud
For SDKs, dashboard authoring, and extension guides, visit: https://developer.serviceradar.cloud
Contributions are welcome! Please feel free to submit a Pull Request. Join our Discord!
Apache 2.0 License - see the LICENSE file for details.