feat: network sweeper / ui #715

New issue

Closed

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

mfreeman451 commented

2026-03-28 04:27:45 +00:00

Owner

Imported from GitHub.

Original GitHub issue: #2248
Original author: @mfreeman451
Original URL: https://github.com/carverauto/serviceradar/issues/2248
Original created: 2026-01-11T18:32:31Z

Is your feature request related to a problem?

The serviceradar-agent (golang) has a network sweeper capability (high-speed TCP syn half-open scanner and also a high-performance ICMP scanner) that is enabled by creating a configuration that defines the scope of the scan, including network addresses (single IP addresses need to be represented in /32 CIDR form), and what ports/protocols we want to check for.

Users need to be able to go into the UI and perform bulk edit of devices across a selection of devices or the entire inventory and configure these network scanner settings. Based on this, we need to generate a new config for this service. Users should be able to choose what partition and optionally select which agent they want to use (partition is mandatory, 'default' is always available, once a partition is selected, if they dont select an agent, any available agent operating in the 'default' partition should be able to deliver the config over GRPC to the agent and start the work. serviceradar-agent has to poll using GRPC to get its config and does so periodically.

We also need a new 'Network' section in the settings UI where Admins can also control the settings for the scanner and choose what protocols/ports are even available, possibly creating "scanner profiles" that operators/users in that tenant can use.

The 2nd part of this is that, historically these results from the agents were collected via poller and then forwarded to the core, our new architecture is that agents push everything up to the agent-gateway (external checkers push to agents), the agent-gateway is tenant aware (mTLS verification) and sends the data to the core for processing.

We need to validate that this process or this new process is implemented in serviceradar-agent for sweepResults, that they get sent to the agent-gateway, and that the agent-gateway knows how to forward to core-elx using RPC/chunking/streaming, and that the core knows what to do with this data (I believe this data gets run through DIRE, device identity and reconciliation engine), updating ocsf_devices and so forth, enriching device records with availability data essentially.

Admins should be able to view configured sweep jobs from the Settings UI under a new Networks tab area and be able to edit/delete configured sweep jobs. The Admin UI should also track these jobs and indicate when they were last run and so on, some operational status, etc.

Admins should also be able to configure sweep jobs from this Admin/Settings UI as well, and not just through a bulk edit operation. Admins should have the ability to select devices based on some property, like a range of IP addresses, CIDR block, tags (discovery_sources), partition, etc, so that for example, an admin can configure a sweep job for any device with 'armis' set as a discovery_source in the 'default' partition and it gets picked up by any agent in the default partition.

Describe the solution you'd like

A clear and concise description of what you want to happen.

Describe alternatives you've considered

A clear and concise description of any alternative solutions or features you've considered.

Additional context

Add any other context or screenshots about the feature request here.

Imported from GitHub. Original GitHub issue: #2248 Original author: @mfreeman451 Original URL: https://github.com/carverauto/serviceradar/issues/2248 Original created: 2026-01-11T18:32:31Z --- **Is your feature request related to a problem?** The serviceradar-agent (golang) has a network sweeper capability (high-speed TCP syn half-open scanner and also a high-performance ICMP scanner) that is enabled by creating a configuration that defines the scope of the scan, including network addresses (single IP addresses need to be represented in /32 CIDR form), and what ports/protocols we want to check for. Users need to be able to go into the UI and perform bulk edit of devices across a selection of devices or the entire inventory and configure these network scanner settings. Based on this, we need to generate a new config for this service. Users should be able to choose what partition and optionally select which agent they want to use (partition is mandatory, 'default' is always available, once a partition is selected, if they dont select an agent, any available agent operating in the 'default' partition should be able to deliver the config over GRPC to the agent and start the work. serviceradar-agent has to poll using GRPC to get its config and does so periodically. We also need a new 'Network' section in the settings UI where Admins can also control the settings for the scanner and choose what protocols/ports are even available, possibly creating "scanner profiles" that operators/users in that tenant can use. The 2nd part of this is that, historically these results from the agents were collected via poller and then forwarded to the core, our new architecture is that agents push everything up to the agent-gateway (external checkers push to agents), the agent-gateway is tenant aware (mTLS verification) and sends the data to the core for processing. We need to validate that this process or this new process is implemented in serviceradar-agent for sweepResults, that they get sent to the agent-gateway, and that the agent-gateway knows how to forward to core-elx using RPC/chunking/streaming, and that the core knows what to do with this data (I believe this data gets run through DIRE, device identity and reconciliation engine), updating ocsf_devices and so forth, enriching device records with availability data essentially. Admins should be able to view configured sweep jobs from the Settings UI under a new Networks tab area and be able to edit/delete configured sweep jobs. The Admin UI should also track these jobs and indicate when they were last run and so on, some operational status, etc. Admins should also be able to configure sweep jobs from this Admin/Settings UI as well, and not just through a bulk edit operation. Admins should have the ability to select devices based on some property, like a range of IP addresses, CIDR block, tags (discovery_sources), partition, etc, so that for example, an admin can configure a sweep job for any device with 'armis' set as a discovery_source in the 'default' partition and it gets picked up by any agent in the default partition. **Describe the solution you'd like** A clear and concise description of what you want to happen. **Describe alternatives you've considered** A clear and concise description of any alternative solutions or features you've considered. **Additional context** Add any other context or screenshots about the feature request here.