chore: doc updates #755

New issue

Closed

opened 2026-03-28 04:28:12 +00:00 by mfreeman451 · 0 comments

mfreeman451 commented

2026-03-28 04:28:12 +00:00

Owner

Imported from GitHub.

Original GitHub issue: #2316
Original author: @mfreeman451
Original URL: https://github.com/carverauto/serviceradar/issues/2316
Original created: 2026-01-15T07:27:06Z

We've made a lot of changes and need to do some major documentation updates here, here is whaths changed:

serviceradar-core (golang): this has been replaced with core-elx (serviceradar-core-elx), written in elixir. the new core creates a horde cluster (distributed ERTS) between web-ng, agent-gateway, and itself and is responsible for DIRE (Device Identity and Reconciliation Engine), internal event routing, and processing status updates or agent data collections. serviceradar-core primarily communicates with other nodes in the cluster using ERTS RPC over mTLS.
serviceradar-poller (golang): this has been completely removed, we no longer use the poller model where the poller communicated with the agent, the agent would either perform the action itself if it could or reach out ot an external checker over GRPC, perform some action and collect data, then finally push it back to the core over GRPC
serviceradar-agent (golang): this remains from the legacy architecture and has been extended with new capabilities. the agent now has serviceradar-sync capabilities baked into it, along with the snmp-checker, and the mapper/discovery engine, along with the network sweep/scanner (tcp/icmp), along with sysmon. the agent is the primary endpoint / agent that will get installed on edge devices. the agent pushes everything (status/results) to the agent-gateway
serviceradar-agent-gateway (elixir): the agent-gateway listens for connections from the agent over GRPC and pushes them to the core. it supports a GRPC method for pushing simple status checks, and a more robust unary GRPC (streaming) endpoint that supports chunking for large payloads (sync, sweep, sysmon)
serviceradar-sysmon (rust): consolidated and built into the agent, rewritten completely in golang
serviceradar-sysmon-osx (golang): consolidated into agent
serviceradar-web (react/nextjs): completely gone and replaced with web-ng
serviceradar-web-ng (elixir/phoenix liveview/react-phoenix): new elixir/phoenix liveview based web front end and API, will also have MCP, we use react-phoenix for the zen rule engine JDM rule editor (3rd-party, OSS)
serviceradar-sync (golang): responsible for communicating with IPAM/integration points, can live in cluster or in the edge, but now baked into the agent. UI for pushing configs is all done in web-ng
Agents/Checkers no longer look to the KV for their config, they get it over GRPC from the agent-gateway->core-elx, configs are compiled by web-ng config compilers for each service that requires dynamic/centralized configurations
Collectors that used to get their config from the KV will drop the KV requirement and just use filesystem config.json/yaml files
need to scrub any mention about multi-tenancy from the docs/architecture docs
update architecture / mermaid diagrams
update README.md
preferred installation method is kubernetes or docker compose
standalone installations only supported for checkers/agents due to CNPG requirement

Imported from GitHub. Original GitHub issue: #2316 Original author: @mfreeman451 Original URL: https://github.com/carverauto/serviceradar/issues/2316 Original created: 2026-01-15T07:27:06Z --- We've made a lot of changes and need to do some major documentation updates here, here is whaths changed: - serviceradar-core (golang): this has been replaced with core-elx (serviceradar-core-elx), written in elixir. the new core creates a horde cluster (distributed ERTS) between web-ng, agent-gateway, and itself and is responsible for DIRE (Device Identity and Reconciliation Engine), internal event routing, and processing status updates or agent data collections. serviceradar-core primarily communicates with other nodes in the cluster using ERTS RPC over mTLS. - serviceradar-poller (golang): this has been completely removed, we no longer use the poller model where the poller communicated with the agent, the agent would either perform the action itself if it could or reach out ot an external checker over GRPC, perform some action and collect data, then finally push it back to the core over GRPC - serviceradar-agent (golang): this remains from the legacy architecture and has been extended with new capabilities. the agent now has serviceradar-sync capabilities baked into it, along with the snmp-checker, and the mapper/discovery engine, along with the network sweep/scanner (tcp/icmp), along with sysmon. the agent is the primary endpoint / agent that will get installed on edge devices. the agent pushes everything (status/results) to the agent-gateway - serviceradar-agent-gateway (elixir): the agent-gateway listens for connections from the agent over GRPC and pushes them to the core. it supports a GRPC method for pushing simple status checks, and a more robust unary GRPC (streaming) endpoint that supports chunking for large payloads (sync, sweep, sysmon) - serviceradar-sysmon (rust): consolidated and built into the agent, rewritten completely in golang - serviceradar-sysmon-osx (golang): consolidated into agent - serviceradar-web (react/nextjs): completely gone and replaced with web-ng - serviceradar-web-ng (elixir/phoenix liveview/react-phoenix): new elixir/phoenix liveview based web front end and API, will also have MCP, we use react-phoenix for the zen rule engine JDM rule editor (3rd-party, OSS) - serviceradar-sync (golang): responsible for communicating with IPAM/integration points, can live in cluster or in the edge, but now baked into the agent. UI for pushing configs is all done in web-ng - Agents/Checkers no longer look to the KV for their config, they get it over GRPC from the agent-gateway->core-elx, configs are compiled by web-ng config compilers for each service that requires dynamic/centralized configurations - Collectors that used to get their config from the KV will drop the KV requirement and just use filesystem config.json/yaml files - need to scrub any mention about multi-tenancy from the docs/architecture docs - update architecture / mermaid diagrams - update README.md - preferred installation method is kubernetes or docker compose - standalone installations only supported for checkers/agents due to CNPG requirement

Rows
Columns