Skip to main content

Collection Methods & Protocols

The Ozone Data Collector talks to devices through a single plugin-based universal collector, not a fleet of per-protocol containers. It ships 63 onboarding methods across 10 device categories, exposed to the WebUI by GET /api/v1/collector/methods. Passive receivers listen on the LAN out of the box; active pollers stay disabled until you onboard a device, so a fresh appliance makes no error noise. This page is the catalog: what the collector can speak, how to onboard a device, and how it fingerprints things it finds on the network.

1. The 63-method catalog​

The catalog spans 63 onboarding methods across 10 categories. The WebUI onboarding wizard always enumerates the current live set from GET /api/v1/collector/methods. The representative methods per category are below; the method names are concrete enum entries the wizard offers.

CategoryCountMethods
network12snmp_v2c, snmp_v3, snmp_trap, netflow_v5, netflow_v9, ipfix, sflow, gnmi, netconf, restconf, syslog, Cisco Catalyst SD-WAN (vManage)
wireless6Cisco WLC 9800, Cisco DNA Center, Cisco Meraki, Aruba Central, Ubiquiti UniFi, Ruckus SmartZone
compute5ssh, redfish, ipmi (iDRAC/iLO), wmi, winrm
storage5NetApp ONTAP, Pure Storage, Dell EMC, HPE Alletra, Ceph
virtualization5VMware vCenter, Nutanix Prism, Hyper-V, Proxmox VE, KVM/libvirt
container3Kubernetes, Docker, OpenShift
cloud5AWS CloudWatch, Azure Monitor, GCP Monitoring, Oracle OCI, Juniper Mist
observability5OTel gRPC, OTel HTTP, Prometheus scrape, StatsD, Jaeger
security10Palo Alto PAN-OS, Fortinet FortiOS, Check Point, Cisco Firepower (FMC), Cisco ASA, Cisco FTD, Juniper SRX, SonicWall, Sophos, WatchGuard
loadbalancer7F5 BIG-IP, Citrix ADC, A10 Thunder, VMware Avi, Kemp, HAProxy, NGINX Plus

Multi-vendor SNMP and flow decode​

  • SNMP. The network plugin ships 29 SNMP vendor profiles and classifies each device automatically, matching on sysObjectID first and falling back to sysDescr, so the right profile and metric set are applied without manual vendor selection.
  • Flow. NetFlow v9 and IPFIX are fully template-decoded into per-flow records; NetFlow v5 uses its fixed record layout. sFlow is summary-level only (sampled counters and headers), not full per-flow decode.
  • Firewalls. The security category covers 11 firewall platforms with authenticated API collection: Palo Alto, Fortinet, Check Point, Cisco FMC/ASA/FTD, Juniper SRX, SonicWall, Sophos, WatchGuard, and F5.

2. The 5 runtime domain plugins​

Continuous polling and listeners are owned by the plugin engine. The 63 methods above are served by five runtime domain plugins, so most methods share a small amount of collector code rather than each running its own container:

  • network covers SNMP, flow, streaming telemetry (gNMI, NETCONF, RESTCONF), and syslog.
  • compute covers SSH, Redfish, IPMI, WMI, and WinRM against servers and out-of-band controllers.
  • virtualization covers the hypervisor and private-cloud managers (vCenter, Prism, Hyper-V, Proxmox, KVM/libvirt).
  • cloud covers the public-cloud monitoring APIs (CloudWatch, Azure Monitor, GCP Monitoring, OCI).
  • facility covers building and power infrastructure over Modbus/TCP and BACnet/IP.

The facility plugin is a runtime collector for OT ingestion (Modbus/TCP and BACnet/IP): it runs continuously to pull power and environmental telemetry, but it is not one of the 10 onboarding-wizard categories, so you will not find "facility" as an add-a-device method in the wizard.

Wireless, storage, container, observability, security, and loadbalancer methods are onboarded the same way and reuse these plugin collectors where the transport matches.

Architect's Note

Treat the Compose stack and the universal collector as ground truth: one collector, five domain plugins, 63 methods. SNMP polling runs inside the universal collector; there is no separate snmp-poller service.

3. Passive receivers on, active pollers off​

Passive receivers listen on the LAN as soon as the appliance boots. Active pollers ship disabled with empty target tables, so the collector generates no failed-poll noise before you have onboarded anything. You turn a poller on by onboarding a device (Section 5).

Receiver ports (LAN-side, on the host firewall)​

Port / ProtoReceiver
162 / UDPSNMP trap
2055 / UDPNetFlow v5
9995 / UDPNetFlow v9
4739 / UDPIPFIX
6343 / UDPsFlow
514 / UDPSyslog
8125 / UDPStatsD
4317 / TCPOTLP gRPC
4318 / TCPOTLP HTTP

Active pollers reach out from the appliance to devices on their own ports, most commonly 161/UDP (SNMP get), 22/TCP (SSH), 443/TCP (Redfish and vendor REST), and 623/UDP (IPMI). See the Firewall & Network guide for the full inbound and outbound picture.

note

SNMP trap on 162/UDP is a privileged port. On a hardened host it needs root or a lowered net.ipv4.ip_unprivileged_port_start.

4. SNMPv3 authentication and privacy​

SNMPv3 support is full. The security level is derived automatically from which passwords you set: no passwords gives noAuthNoPriv, an auth password alone gives authNoPriv, and both gives authPriv.

LayerSupported algorithms
Authentication (auth)SHA, MD5, SHA-224, SHA-256, SHA-384, SHA-512
Privacy (priv)AES-128, AES-192, AES-256, DES, 3DES
Auth set?Priv set?Security level
NoNonoAuthNoPriv
YesNoauthNoPriv
YesYesauthPriv

5. The unified onboarding wizard​

Every device, of every category and method, is onboarded through one 4-step wizard that posts to a single endpoint. There is no per-protocol form.

  • Step 1, Category picks one of the 10 device categories.
  • Step 2, Method picks one of that category's methods. The wizard requests the fields that method needs, for example a WMI target asks for host, username, password, and domain.
  • Step 3, Details captures the host or address, credentials, poll interval, tags, and optional serial number and location.
  • Step 4, Done submits POST /api/v1/collector/devices (HTTP 201 on success). The device row enforces UNIQUE(host, collection_method), so the same host can be onboarded under more than one method (for example SNMP and SSH) but never twice under the same method.

Onboarding a device is what flips its poller from dormant to active. Credentials and the collection method are write-once on create: to change a method, delete and re-add the device.

6. Auto-discovery fingerprinting​

The auto-discovery service sweeps a subnet and proposes devices for onboarding, so you rarely type in hosts by hand. For each responsive address it fingerprints what the device is likely to be by combining:

  • a TCP port scan of roughly 40 common service ports,
  • ICMP reachability,
  • reverse DNS on the address, and
  • an SNMP sysDescr read where a community or v3 credential is available.

From that evidence it guesses a category and a plausible collection method, then hands the candidate to the same onboarding wizard in Section 5 so an operator confirms credentials before the poller goes live. Auto-discovery needs NET_RAW / NET_ADMIN, which the shipped Compose already grants.

Where next​