<div align=center>

</div>

ServiceRadar

<img width="1470" height="836" alt="Screenshot 2025-12-16 at 10 09 19 PM" src="https://github.com/user-attachments/assets/e64ca26b-f4d8-42df-ab81-2de1d7941f92" /> <img width="1470" height="801" alt="Screenshot 2026-02-16 at 8 39 36 PM" src="https://github.com/user-attachments/assets/4f959217-4e53-487b-ae78-30c2fd3344b3" /> <img width="1470" height="804" alt="Screenshot 2026-02-16 at 8 36 26 PM" src="https://github.com/user-attachments/assets/bec3d2cb-c311-4a26-848d-2fece4a5af86" /> <img width="1470" height="801" alt="Screenshot 2026-02-16 at 8 37 08 PM" src="https://github.com/user-attachments/assets/0384520a-755f-4bdd-843a-a41f02d7c439" />

https://github.com/user-attachments/assets/1cf2b90a-06f4-4ba7-b229-79720b16e0aa

<a href="https://cla-assistant.io/carverauto/serviceradar"><img src="https://cla-assistant.io/readme/badge/carverauto/serviceradar" alt="CLA assistant" /></a>

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@localhost 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.
• Topology: GPU-native topology engine capable of rendering millions of interactive nodes and edges at 60fps via deck.gl, Apache Arrow for zero-copy streaming, and WASM-native logic layer.
• 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.
• SRQL: intuitive key:value syntax for querying time-series and relational data.
• Unified Data Layer: Powered by CloudNativePG, TimescaleDB, and Apache AGE for relational, time-series, and graph topology data.
• 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.
• Security: Hardened with mTLS (SPIFFE/SPIRE on Kubernetes), RBAC, and SSO integration.

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 -- Coming Soon

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 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 GHCR as an OCI artifact.

# Inspect chart metadata and default values
helm show chart oci://ghcr.io/carverauto/charts/serviceradar --version 1.1.1
helm show values oci://ghcr.io/carverauto/charts/serviceradar --version 1.1.1 > values.yaml

# Install a pinned release (recommended)
helm upgrade --install serviceradar oci://ghcr.io/carverauto/charts/serviceradar \
  --version 1.1.1 \
  -n serviceradar --create-namespace \
  --set global.imageTag="v1.1.1"

# Track mutable images (staging/dev): pulls :latest and forces re-pull
helm upgrade --install serviceradar oci://ghcr.io/carverauto/charts/serviceradar \
  --version 1.1.1 \
  -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

Note: if you omit global.imageTag, the chart defaults to latest. Set global.imagePullPolicy=Always when you want to pick up new pushes on restart.

Docker Compose notes:

• Set APP_TAG in .env to pin release images (example: APP_TAG=v1.1.1).
• Set COMPOSE_FILE=docker-compose.yml:docker-compose.dev.yml in .env to default to the dev overlay without -f.

Chart URL: oci://ghcr.io/carverauto/charts/serviceradar

Notes:

• Chart versions are like 1.1.1; ServiceRadar image tags are like v1.1.1.
• If your cluster requires registry credentials, set image.registryPullSecret (default ghcr-io-cred).

For ArgoCD deployments, use ghcr.io/carverauto/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: ghcr.io/carverauto/charts
    chart: serviceradar
    targetRevision: "1.1.1"
    helm:
      values: |
        global:
          imageTag: "v1.1.1"

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).
4. Web UI (web-ng): Real-time LiveView dashboard 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.).

Documentation

For detailed guides on setup, security, and WASM SDK usage, visit: https://docs.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.