ServiceRadar

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: [email protected] password: serviceradar

Features

• 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.
• ServiceRadar Atlas: GPU-native topology map of the whole estate. World tiles render with deck.gl and Apache Arrow, bounded scenes use a WASM logic layer, and a server-side roaring bitmap index filters the map by inventory attributes. See Network Topology.
• 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: CloudNativePG (PostgreSQL with TimescaleDB and pgvector) holds inventory, configuration and current state, and Dgraph is the topology graph store behind ServiceRadar Atlas. See docs/network-topology.md.
• StarRocks Telemetry Warehouse: an optional StarRocks warehouse becomes the system of record for flows, metrics, logs, events, OTel metrics and traces, MTR and BMP. Retention is set per dataset in the UI and defaults to one year. Run it shared-nothing on local disks, or shared-data, where tables live in S3-compatible object storage as a data lake and compute nodes cache hot data, so storage grows without adding compute. NetFlow and process-to-flow attribution require it; without it, telemetry is stored in CloudNativePG.
• 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/IPFIX (netflow_parser). Telemetry goes through NATS JetStream before it is stored, so real-time consumers such as anomaly detection see it as it arrives.
• 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.

WASM-Based Extensibility

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.

Plug-in SDK

Go: https://github.com/carverauto/serviceradar-sdk-go

Rust: https://github.com/carverauto/serviceradar-sdk-rust

Dashboard SDK

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/dashboard@latest my-dashboard -- --template react-map
cd my-dashboard
npm ci
npm run dev

Use 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

Quick Installation (Docker Compose)

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-updater

Access: http://localhost (login: root@localhost)

Kubernetes / Helm Deployment

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 -d

To store telemetry in StarRocks, deploy a StarRocks cluster with the StarRocks Kubernetes operator (the profiles ServiceRadar is tested with are in k8s/starrocks/), then point the chart at its frontend in my-values.yaml. The shared-data profile keeps the tables in an S3-compatible bucket, and the chart creates the StarRocks storage volume for it; the Secret holds access_key_id and secret_access_key. Either profile also needs catalog.fePasswordSecretName: a Secret in the ServiceRadar release namespace whose password key holds the StarRocks Frontend root password, the same value as the StarRocks operator's initPassword Secret (see Frontend root password):

analytics:
  starrocks:
    enabled: true
    profile: sharedData          # or sharedNothing for local disks
    fe:
      service: starrocks-fe-service.starrocks.svc
    catalog:
      fePasswordSecretName: starrocks-fe-root-password
    sharedData:
      objectStorageBucket: serviceradar-warehouse
      objectStorageEndpoint: https://s3.example.com
      objectStorageRegion: us-east-1
      secretName: starrocks-object-store

Note: 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.

Verifying Published Images

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.49

For 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-ac23dc0ebcbee0d6a964dc8307826bf2a063536c

Successful 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-ac23dc0ebcbee0d6a964dc8307826bf2a063536c

Docker Compose notes:

• Set APP_TAG in .env to pin release images (example: APP_TAG=v1.4.49).
• Set COMPOSE_FILE=docker-compose.yml:docker-compose.dev.yml in .env to 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 like v1.4.49.
• Published images pull anonymously, so no registry credentials are needed. image.registryPullSecret (default registry-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.

Architecture

1. Agent: Lightweight Go service on monitored hosts; manages WASM execution and local collection.
2. Agent-Gateway: Ingestion point that receives gRPC streams from edge agents.
3. Core (core-elx): Control plane (Elixir/Phoenix/Ash) for orchestration, ERTS, and job scheduling (Oban). Its EventWriter consumes the JetStream telemetry streams and writes them to StarRocks, or to CloudNativePG when the warehouse is off.
4. Web UI (web-ng): Real-time LiveView dashboard, ServiceRadar Atlas, and APIs for configuration and visualization.
5. NATS: NATS JetStream message broker for bulk ingestion streams.
6. Collectors: Collect bulk data (netflow, logs, SNMP, etc.).
7. Storage: CloudNativePG for inventory and current state, Dgraph for the topology graph, and the optional StarRocks warehouse (local disks or S3-backed) for telemetry.

Documentation

For detailed guides on setup and security, visit: https://docs.serviceradar.cloud

For SDKs, dashboard authoring, and extension guides, visit: https://developer.serviceradar.cloud

Contributing

Contributions are welcome! Please feel free to submit a Pull Request. Join our Discord!

License

Apache 2.0 License - see the LICENSE file for details.