ksmith/OrbitWard
1
0
Fork 0
Code Issues 12 Pull Requests Actions Packages Projects Releases Wiki Activity

Add SNMP profile mapping for friendly metric names #16

New Issue
Closed
opened 2026-05-23 15:46:01 -06:00 by Agent · 5 comments
Agent commented 2026-05-23 15:46:01 -06:00
Copy Link
Copy Source

Add a profile mapping layer that translates SNMP implementation details into friendly monitorable names and device health categories. Raw OIDs should remain behind profiles or advanced/internal tooling.

Scope should include:

  • Friendly interface names, status, traffic, errors, discards, and speed.
  • Device uptime and system identity.
  • Host resource discovery for CPU, memory, disk/storage, and other standard host health data when supported.
  • Sensor and environmental health mapping where supported by common device/vendor profiles.
  • Vendor/profile-specific mappings that can expose friendly labels without showing raw OIDs in the normal UI.
  • Clear capability flags so unsupported CPU, memory, disk, or sensor data simply does not appear instead of failing discovery.

The guided UI should continue to show friendly labels such as "CPU load", "Memory used", "Disk / usage", "Power supply status", or "Temperature", not raw OIDs.

Add a profile mapping layer that translates SNMP implementation details into friendly monitorable names and device health categories. Raw OIDs should remain behind profiles or advanced/internal tooling. Scope should include: - Friendly interface names, status, traffic, errors, discards, and speed. - Device uptime and system identity. - Host resource discovery for CPU, memory, disk/storage, and other standard host health data when supported. - Sensor and environmental health mapping where supported by common device/vendor profiles. - Vendor/profile-specific mappings that can expose friendly labels without showing raw OIDs in the normal UI. - Clear capability flags so unsupported CPU, memory, disk, or sensor data simply does not appear instead of failing discovery. The guided UI should continue to show friendly labels such as "CPU load", "Memory used", "Disk / usage", "Power supply status", or "Temperature", not raw OIDs.
Agent commented 2026-05-26 16:08:52 -06:00
Author
Copy Link
Copy Source

Implemented in the local working tree: internal SNMP profile selection, discovery capability flags, friendly HOST-RESOURCES CPU/memory/storage items, friendly ENTITY-SENSOR items, worker collection for CPU/memory/storage/sensor monitors, frontend display of profile/capabilities, and focused tests.

Created follow-up #18 for vendor-private mappings from real device examples. Leaving this issue open until the changes are reviewed/committed.

Implemented in the local working tree: internal SNMP profile selection, discovery capability flags, friendly HOST-RESOURCES CPU/memory/storage items, friendly ENTITY-SENSOR items, worker collection for CPU/memory/storage/sensor monitors, frontend display of profile/capabilities, and focused tests. Created follow-up #18 for vendor-private mappings from real device examples. Leaving this issue open until the changes are reviewed/committed.
Agent commented 2026-05-26 16:34:23 -06:00
Author
Copy Link
Copy Source

Completed by commit e59733d: added internal SNMP profile mapping, capability-aware discovery, standard CPU/memory/storage/sensor monitorable items, worker collection support, UI metadata, and tests. Vendor-private mappings are tracked separately in #18.

Completed by commit e59733d: added internal SNMP profile mapping, capability-aware discovery, standard CPU/memory/storage/sensor monitorable items, worker collection support, UI metadata, and tests. Vendor-private mappings are tracked separately in #18.
Agent closed this issue 2026-05-26 16:34:23 -06:00
Agent commented 2026-05-26 16:36:28 -06:00
Author
Copy Link
Copy Source

Reopened after user verification. The implemented standard SNMP mapping works technically, but the discovered names are still not friendly enough for normal UI use. Further work is needed to normalize interface and health item labels into clearer user-facing names without exposing raw SNMP details. Asset deletion cleanup in #19 remains accepted.

Reopened after user verification. The implemented standard SNMP mapping works technically, but the discovered names are still not friendly enough for normal UI use. Further work is needed to normalize interface and health item labels into clearer user-facing names without exposing raw SNMP details. Asset deletion cleanup in #19 remains accepted.
Agent reopened this issue 2026-05-26 16:36:29 -06:00
Agent commented 2026-05-26 19:43:49 -06:00
Author
Copy Link
Copy Source

Progress update: commit 6ff452a improves #16 with asset-type-driven SNMP discovery, friendlier network interface labels, Proxmox/Linux server profile selection, Linux/UCD plus HOST-RESOURCES server health discovery, server interface exposure, and Linux collector support. Leaving this issue open because the friendly naming/profile mapping still needs more real-device validation and polish.

Progress update: commit 6ff452a improves #16 with asset-type-driven SNMP discovery, friendlier network interface labels, Proxmox/Linux server profile selection, Linux/UCD plus HOST-RESOURCES server health discovery, server interface exposure, and Linux collector support. Leaving this issue open because the friendly naming/profile mapping still needs more real-device validation and polish.
Agent commented 2026-05-26 21:08:24 -06:00
Author
Copy Link
Copy Source

Completed in af72a6c.

Implemented SNMP profile/discovery improvements including friendly server/network profile selection, Linux/Proxmox health items, friendlier interface labels, editable asset SNMP setup flow, and current observed values in SNMP scan results.

Verified:

  • docker compose -f docker-compose.dev.yml run --rm backend sh -c "pip install -e '.[test]' >/dev/null && python -m pytest tests/test_discovery.py"
  • docker compose -f docker-compose.dev.yml run --rm frontend npm run typecheck
  • git diff --check
Completed in `af72a6c`. Implemented SNMP profile/discovery improvements including friendly server/network profile selection, Linux/Proxmox health items, friendlier interface labels, editable asset SNMP setup flow, and current observed values in SNMP scan results. Verified: - `docker compose -f docker-compose.dev.yml run --rm backend sh -c "pip install -e '.[test]' >/dev/null && python -m pytest tests/test_discovery.py"` - `docker compose -f docker-compose.dev.yml run --rm frontend npm run typecheck` - `git diff --check`
Agent closed this issue 2026-05-26 21:08:25 -06:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
ksmith
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: ksmith/OrbitWard#16
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?