ServiceRadar puts the monitoring agent behind a WASM sandbox and a network bridge

Agent, Gateway and Core, and why the split exists

ServiceRadar is described as 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 so you stay informed during network or power outages.

That last sentence is the design brief. A monitoring system that only alerts when the network it monitors is up is not much use in the situation where monitoring matters most. The distributed architecture answers that: the features list describes a multi-component design of Agent, Gateway and Core for flexible edge deployments, and monitoring happens with ICMP and TCP checks from vantage points that are close to what they watch.

The composite check capability is the concrete expression of that. The README says you can create composite service checks from multiple vantage points by deploying serviceradar-agent in edge or segmented networks. So a service is not healthy because one probe says so; it is healthy because probes in different segments agree.

The project is also honest about its current shape in a small way. The unified data layer is powered by CloudNativePG, TimescaleDB and PGVector for relational, time-series and vector data, with Dgraph as the topology graph store, and the README notes that Apache AGE still runs beside it during the rollout. A data platform mid-migration is a fact of the current release rather than a design intent, and it is the kind of detail that affects how much database surgery an upgrade involves.

The primary language is Elixir, but the repository is polyglot by necessity. The Cargo workspace lists Elixir NIF crates alongside Rust services such as the anomaly core, the correlation engine, the SRQL implementation and the collectors for BGP, NetFlow, SNMP traps, OTEL and eBPF, and the Go module carries SNMP, eBPF, SPIFFE and OTEL libraries. The web UI and the data plane are written in different languages on purpose.

Plugins are WASM modules that cannot touch the filesystem

The extensibility model is the most consequential design decision in the project, and it is a direct contrast with how classical network management systems work.

ServiceRadar replaces traditional script-and-shell plugins with a modern WebAssembly runtime, and the README says this provides a generation leap in security and portability. The comparison table in the README sets out the claim. ServiceRadar is listed with hardware sandbox isolation, zero dependencies from static binaries, capability-based security through a proxy, cross-platform WASM portability, and every network call logged as the auditability property. The traditional network management system column, Nagios and Zabbix, is listed with no isolation because the plugin is an OS process, high dependencies from local libraries or Python, sudo or root access, script-specific portability, and a network call that is invisible to the agent. The enterprise column, SolarWinds, is listed with no isolation because the plugin runs in a user session, high dependencies, local admin or WMI access, Windows-centric portability, and opaque behaviour.

The mechanism underneath is the Network Bridge. 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 and TCP calls based on admin-approved allowlists.

That is the constraint every custom check has to live within. A plugin can make an HTTP request to a host that an administrator has allowed. It cannot open a socket, read a config file, or run a shell command. For a monitoring check that is often enough, and for a monitoring check that needs to run an arbitrary script on a remote host, it is not.

Plugins can be written in Go or Rust, and the project publishes separate SDKs for both languages, hosted under the carverauto organisation. The runtime is wazero, which is a pure Go WebAssembly runtime rather than one requiring a C runtime or an operating system facility.

SRQL, the anomaly engine and the causal engine

Three engines do the analytical work, and they are worth separating because they sit at different points in the pipeline.

SRQL is described as an intuitive key:value syntax for querying time-series and relational data. It is the query language the dashboards consume, and the Dashboard SDK hands dashboards SRQL-backed data frames, so SRQL is the interface between the UI and the data layer rather than an internal detail.

The Anomaly Engine scores numeric time series in two places. At the edge it uses median and MAD based spike detection plus CUSUM drift, and in core it computes seasonal hour-of-week baselines, episode lifecycle, severity and capacity runway. The behaviour that matters operationally is that findings are episode-bounded, with open, update and clear states plus cooldowns and storm shedding, so operators get durable alerts instead of noisy per-sample alarms. That is a design statement about alert fatigue, and it is the difference between a monitoring tool and an alerting tool.

The Causal Engine does triage and isolation using DeepCausality, which is written in Rust. It employs hybrid filtering and roaring bitmaps to identify root causes and visually isolate an event's blast radius in microseconds. The roaring bitmap choice is the interesting one, because it is a compressed bitmap structure designed for sets of integers, which is what makes the isolation fast.

Then there is the Graph Network Mapper, a discovery engine that maps interfaces and topology relationships via SNMP, LLDP and CDP, and the Topology view, which the README describes as GPU-native, with bounded world tiles using deck.gl and Apache Arrow, and bounded scenes using a WASM logic layer.

Observability ingest is broad: native support for OTEL, GELF, Syslog, SNMP with polling and traps, BGP through BMP, and NetFlow.

Notifications with a delivery log, and Ansible playbooks on the inventory

Alerting is where most monitoring products are weakest, so this is where the README is most specific.

Notifications turn an alert into a page through routes, escalation policies and channels, and the channel list includes Slack, Discord, email and webhooks, plus declarative and Wasm providers. Two properties are called out as deliberate design. Every attempt, including silences and withheld sends, is written to the Delivery Log, so you can see what was suppressed and why. And retry, failover and escalation are kept as three separate knobs, so a flaky channel does not silently change your paging behaviour.

That last point matters more than it sounds. In many systems a single retry policy setting conflates three different decisions: whether to try again, which alternative channel to use, and when to escalate. Splitting them means you can set them to suit each channel.

The Ansible integration runs AWX or AAP playbooks against devices in the inventory, with live per-host run telemetry projected to OCSF for a universal log viewer. AWX-sourced and git-sourced playbook catalogs coexist, and cron-driven schedules ride the same launch pipeline. Running a playbook is therefore treated as an observation-producing action rather than a side channel.

The security story is stated in the features list: hardened with mTLS, RBAC and SSO integration, build images, WASM plugins and add-ons are signed, and SBOMs ship with every build. The repository backs that up with a SECURITY.md file, SECURITY_CONTACTS.md, a TELEMETRY.md file, a CODEOWNERS file, a GOVERNANCE.md file, and a CLA assistant badge.

Building a dashboard package and running it locally

Dashboards are customer-owned packages authored in React and rendered inside the web UI, and the Dashboard SDK gives authors a stable browser-module API for SRQL queries, Arrow-backed data frames, query state, Mapbox and 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 dev

The README then names the three commands that matter. Use npm run dev for the local hot module reloading harness, npm run validate before handing a package to ServiceRadar, and a third command beginning with npx servicerad that the README text truncates before it completes. The truncation is in the README itself, so the exact invocation for that step is not recoverable from the documentation.

That local development loop is the point. Dashboards run inside ServiceRadar but can be developed locally with hot module reloading before publishing, which means the iteration happens in a normal editor and a browser rather than inside the server.

For the platform itself, the repository ships an INSTALL.md file, a README-Docker.md file, DOCKER_QUICKSTART.md, a docker-compose.yml and a Makefile.docker, alongside the Bazel, Go and Rust build configuration. The docker-compose file shows how the database side comes up, with a dedicated certificate generator container producing the mTLS certificates for CloudNativePG.

  cert-generator:
    image: alpine:3.20
    container_name: serviceradar-cert-generator-mtls
    environment:
      - CNPG_CERT_EXTRA_IPS=${CNPG_CERT_EXTRA_IPS:-}
      - CNPG_SUPERUSER=${CNPG_SUPERUSER:-}
      - CNPG_SUPERUSER_FILE=/etc/serviceradar/cnpg/superuser-username

The comment in that file explains the first variable: it is for optional extra SAN entries so clients can connect using a LAN IP.

A build system with three toolchains and a pinned lint version

The repository is large and the build reflects that. The top level carries BUILD.bazel, MODULE.bazel with a lock file, a Cargo workspace, a Go module, a Makefile, and configuration for a broad set of tools including golangci-lint, swiftlint, clang-tidy, gitleaks, buf and syft.

The Makefile is where the pinning decisions are visible. The Go binary, cache and module cache are all overridable variables, and the buf version is pinned to v1.70.0 with buf run through go run. The golangci-lint version is pinned to v2.11.4, and the comment next to it explains why in unusually specific terms: the pin must match the one in the GitHub Actions workflow because the two golangci-lint releases do not agree on what is a finding, with v2.11.4 bundling goconst v1.8.2 and v2.12.2 bundling v1.10.0, and the newer one reporting around seventeen hundred findings in this tree that the pinned one reports none of.

That comment is a small window into how this project is maintained. A linter upgrade is treated as a change with a blast radius, so the version is pinned and the discrepancy is documented rather than absorbed.

The Bazel setup is described in a BUILD.md file and a Bazel.md file, with canonical full-workspace arguments including -c opt --config=remote and cache-proxy targets that reuse existing build and test recipes with target-specific flag overrides so they cannot drift from what developers and CI already run.

The Go module targets go 1.26.3 and pulls in the libraries the Go components need, including cilium/ebpf, gosnmp, nats.go, the OpenTelemetry SDK and the OTLP exporters for logs, metrics and traces, plus SPIFFE and SPIRE libraries for workload identity.

Where ServiceRadar is the wrong choice

The WASM plugin model is a genuine limitation, and it is the first thing to test against your requirements.

If your existing checks are shell scripts, or Python scripts that read local files, or anything that needs a raw socket, they do not port. A plugin cannot open a socket, cannot read the host filesystem, and cannot run a process. You would be rewriting your check inventory, not translating it, and every check that needs privileged local access has no equivalent in this model.

The second limitation is deployment weight. This is a platform, not an agent. The compose file brings up certificate generation, a CloudNativePG migrator, a PostgreSQL 18 expectation in CNPG_EXPECTED_PG_MAJOR, TimescaleDB, Dgraph and PGVector. The build needs Bazel, Go, Rust, Elixir and Node toolchains side by side. If you have one edge box and a week, that is a lot, and the project is aimed at organisations that already have infrastructure teams.

The third is the data layer mid-migration. The README states that Dgraph is the topology graph store and that Apache AGE still runs beside it during the rollout. Two graph stores during a migration means schema and query work for whoever upgrades, and it means the topology features behave differently from the relational and time-series features depending on which store answers.

The fourth is operational surface. The features list mentions mTLS, RBAC, SSO, signed build images, signed WASM plugins and signed add-ons, SBOMs on every build, a Delivery Log, and separate retry, failover and escalation knobs. That is a lot of moving parts, and each is a thing to configure, monitor and eventually debug.

On licensing, the badge and the Makefile header both state Apache 2.0, and the LICENSE file is at the repository root. The copyright line in the Makefile reads Copyright 2025 Carver Automation Corporation. That is permissive enough for most use, and the CLA assistant badge indicates contributions come in through a contributor licence agreement rather than a plain DCO.

Editorial conclusion

Adopt ServiceRadar if you monitor infrastructure in places with unreliable connectivity, if you are replacing shell-script checks that run with sudo on remote hosts, or if you need network monitoring that keeps alerting when the local network or power goes down, since that is the scenario the architecture is built around. Do not adopt it if you want a single-binary agent that installs in five minutes, because the distributed Agent, Gateway and Core design with CloudNativePG, TimescaleDB, Dgraph and Bazel builds is a substantial platform. Before committing, read the demo site documentation and the INSTALL.md file, then verify the plugin SDK for Go or Rust covers the checks you actually need, because the WASM sandbox with no filesystem or raw socket access is the constraint that shapes every custom check.

Frequently asked questions

Official sources

1. carverauto/serviceradar on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases