feat: OCSF agent schema alignment #697

New issue

Closed

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

mfreeman451 commented

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

Owner

Imported from GitHub.

Original GitHub issue: #2179
Original author: @mfreeman451
Original URL: https://github.com/carverauto/serviceradar/issues/2179
Original created: 2025-12-18T05:03:38Z

OCSF Agent Schema alignment

Summary

We need to change the way we represent agents to align with the OCSF agent schema. We currently basically treat agents like devices and that is probably not the way to do that.

This change would mean that agents would no longer show up in the Device UI views, and we will have to work to create a new agent UI view, which is perfectly acceptable.

Background

ServiceRadar pollers (serviceradar-poller) are configured to talk to the agents -- so an agent is added to the configuration, and then you define the specific checks that agent will perform, the poller calls out to that agent and the agent handles the request, either directly or by reaching out to another checker running on the edge, over GRPC. We also have some self-registration stuff going on in the core where we turn the agent into a device if we ever get any information from one, either from a response to a healthcheck (GetStatus GRPC) or a request for a real payload (GetResults GRPC).

OCSF Agent

https://schema.ocsf.io/1.7.0/objects/agent

OCSF Agent Schema (JSON)

https://schema.ocsf.io/schema/1.7.0/objects/agent?profiles=

OCSF Agent Schema (example data)

https://schema.ocsf.io/sample/1.7.0/objects/agent?profiles=

Tasks

Identify functionality in serviceradar-core related to processing Agents.
Self-registration should not turn agent into a device
Update PG schema for agents, should be separate table

Imported from GitHub. Original GitHub issue: #2179 Original author: @mfreeman451 Original URL: https://github.com/carverauto/serviceradar/issues/2179 Original created: 2025-12-18T05:03:38Z --- # OCSF Agent Schema alignment ## Summary We need to change the way we represent agents to align with the OCSF agent schema. We currently basically treat agents like devices and that is probably not the way to do that. This change would mean that agents would no longer show up in the Device UI views, and we will have to work to create a new agent UI view, which is perfectly acceptable. ## Background ServiceRadar pollers (serviceradar-poller) are configured to talk to the agents -- so an agent is added to the configuration, and then you define the specific checks that agent will perform, the poller calls out to that agent and the agent handles the request, either directly or by reaching out to another checker running on the edge, over GRPC. We also have some self-registration stuff going on in the core where we turn the agent into a device if we ever get any information from one, either from a response to a healthcheck (GetStatus GRPC) or a request for a real payload (GetResults GRPC). ## OCSF Agent https://schema.ocsf.io/1.7.0/objects/agent ### OCSF Agent Schema (JSON) https://schema.ocsf.io/schema/1.7.0/objects/agent?profiles= ### OCSF Agent Schema (example data) https://schema.ocsf.io/sample/1.7.0/objects/agent?profiles= ## Tasks - [ ] Identify functionality in serviceradar-core related to processing Agents. - [ ] Self-registration should not turn agent into a device - [ ] Update PG schema for agents, should be separate table