feat(netbox): pull DCIM topology into the service topology map

[aditya-786]

Why are these changes needed?

Towards #3931. Users monitoring physical networks (routers, switches) get alerts from tools like Nagios and Graylog, and when a shared failure hits (the issue describes a rack power loss) hundreds of alerts arrive with no way to correlate them by the physical infrastructure they belong to. NetBox is the source of truth for that infrastructure, but the Keep NetBox provider only received webhook alerts.

This upgrades the NetBox provider to a topology provider, so Keep pulls the DCIM inventory and feeds it to the existing topology map and topology based correlation:

• Devices become services: name (the attribute monitoring tools report alerts with), primary IP, role, manufacturer, site and tags, using the existing TopologyService columns. No migration needed.
• Cables become dependencies: a cable between two known devices creates a service dependency, so the topology map draws the physical connections. Both the current (a_terminations/b_terminations) and pre-3.3 (termination_a/termination_b) cable formats are supported.
• Racks optionally become applications (off by default, opt-in via group_racks_as_applications): devices sharing a rack are grouped into an application named after the rack. With the topology processor enabled (KEEP_TOPOLOGY_PROCESSOR=true), alerts from many devices in the same rack can then be correlated into a single incident, which is the rack power loss scenario from the issue. Application semantics for a physical container is a design choice, which is why it sits behind a flag.

Rack applications use a stable id derived from tenant, provider and rack, so re-pulls update the application in place instead of creating a new one on every pull.

Backward compatibility

The API access fields are all optional and existing webhook-only installs are unaffected:

• With no URL or token configured, pull_topology is a silent no-op and scope validation passes, so the topology polling loop does not produce errors for legacy installs.
• The webhook alert path (_format_alert) is unchanged.
• On configured installs an API failure raises, so a transient NetBox outage never wipes previously pulled topology (process_topology only rewrites on non-empty data).

Scale

Pulling paginates the NetBox API (limit/offset, 1000 per page) with a hard cap (max_devices, default 5000, truncation logged) and excludes config_context from device payloads to keep responses small. Every request carries a timeout, and the SSL verify switch matches the other on-prem providers.

Out of scope (kept for follow-ups)

• No changes to the topology processor or correlation logic.
• No new "infrastructure topology" category or UI work; the existing topology map renders the pulled data as is.
• No AI context integration.

Checks

• I've made sure the tests are passing.
• Testing Strategy
  • Unit tests

tests/providers/netbox_provider/test_netbox_topology.py (17 tests): device and cable mapping (including the legacy cable format and dangling cable ends), rack grouping on and off with stable namespaced application ids, webhook-only no-op with no HTTP calls, pagination, max_devices cap, API error raising, verify wiring, the unchanged webhook alert format, and an end-to-end test through process_topology proving a re-pull is idempotent (services recreated, the rack application updated in place). Existing topology tests (tests/test_topology.py) stay green, and the docs snippet was regenerated with the provider docs updated.

[github-actions]

No linked issues found. Please add the corresponding issues in the pull request description.
Use GitHub automation to close the issue when a PR is merged

[shahargl]

lgtm